Quels sont les avantages d'utiliser «make» pour les petits projets? [fermé]

J'ai vu que makec'est utile pour les grands projets, en particulier avec les dépendances déroutantes décrites dans a Makefile, et aussi pour aider avec le flux de travail. Je n'ai entendu aucun avantage à utiliser makepour de petits projets. Y a-t-il?

Par opposition à quoi?

Supposons que vous ayez un programme que vous avez divisé en deux fichiers, que vous avez nommé file1.cet  imaginativement file2.c. Vous pouvez compiler le programme en exécutant

cc file1.c file2.c -o yourprogram

Mais cela nécessite de recompiler les deux fichiers à chaque fois, même si un seul a changé. Vous pouvez décomposer les étapes de compilation en

cc -c file1.c
cc -c file2.c
cc    file1.o file2.o -o yourprogram

puis, lorsque vous modifiez l'un des fichiers, recompilez uniquement ce fichier (et effectuez l'étape de liaison, peu importe ce que vous avez modifié). Mais que se passe-t-il si vous modifiez un fichier, puis l'autre, et que vous oubliez que vous avez modifié les deux fichiers et recompilé accidentellement un seul?

De plus, même pour seulement deux fichiers, vous disposez d'environ 60 caractères de commandes. Cela devient vite fastidieux à taper. OK, bien sûr, vous pouvez les mettre dans un script, mais vous recommencez à chaque fois. Ou vous pouvez écrire un script compliqué vraiment sophistiqué qui vérifie quels fichiers ont été modifiés et ne fait que les compilations nécessaires. Voyez-vous où je veux en venir?

Beaucoup d'autres personnes entrent dans les détails des makefiles plus complexes et beaucoup de la complexité qui les accompagne. J'utilise généralement des makefiles pour une raison complètement différente:

Je ne veux me souvenir de rien.

Même si votre projet est vraiment ennuyeux et simple, et que vous n'utilisez pas les makefiles "correctement":

all:
    gcc main.c -o project

Je n'ai pas besoin d'y penser ou de le traiter différemment d'un projet plus complexe:

all:
    gcc libA.c libB.c main.c -o project2

Ou si j'ai spécifié des indicateurs (par exemple -O2), je n'ai pas besoin de me rappeler ce qu'ils étaient.

De plus, si vous commencez avec un simple makefile et que vous devez fusionner / refactoriser les choses plus tard, vous n'avez pas besoin de vous rappeler de construire chaque projet différemment.

Même avec un petit projet, il peut être utile de garder la logique de dépendance sous contrôle et les builds automatisés. Je l'ai également utilisé pour déclencher des installations et des désinstallations, c'était donc un interrupteur principal qui réinitialisait la scène.

Si vous liez votre application à partir de 2 sources ( .cfichiers), vous n'avez pas besoin de recompiler chaque fichier, mais uniquement celui modifié si vous utilisez make.

Aussi, je vais vous donner un exemple du monde BSD. Ils ont un cadre de Makefiles basé sur le système. Ils vous fournissent des chemins vers les répertoires système et ont des cibles pour installer votre logiciel et vos pages de manuel.

Par exemple, vous venez d'écrire une beer.capplication et un manuel pour l'appeler beer.6. Vous créez Makefile:

PROG=   beer
MAN=    beer.6

.include <bsd.prog.mk>

..et appel make install. Il compile et installe automatiquement votre application /usr/binet compile et installe votre page de manuel à l'endroit où la mantrouver. Vous venez d'installer votre application avec une seule commande!

Très pratique et absolument transparent pour tous ceux qui connaissent BSD. Beaucoup mieux qu'un script manuel.

Exemple Makefilepour mon tout petit projet:getPixelColor

Il fait exactement ce que son nom dit, en prenant deux arguments facultatifs, les coordonnées.

J'aime particulièrement la façon dont les choses deviennent dépendantes là-bas.

COORDS ?= 0 0

CXX := g++-8
CXXFLAGS := -std=c++17 -Wall -Wextra -Werror -Wpedantic -pedantic-errors
LDLIBS := -lX11
RM := rm -f

BIN := getPixelColor
SRC := $(BIN).cpp

$(BIN): $(SRC)
    $(CXX) $(CXXFLAGS) $(SRC) -o $(BIN) $(LDLIBS)

.PHONY: clean
clean:
    $(RM) $(BIN)

.PHONY: run
run: $(BIN)
    ./$(BIN) $(COORDS)

Comme vous pouvez le voir, il peut faire tout ce dont vous avez besoin, sans rien taper de plus:

Usage

Vous pouvez l'exécuter de cette façon:

1. Nettoyer l'ancien binaire:

   make clean

2. Compilez un nouveau binaire:

   make

3. Exécutez l'exécutable de 2 manières:

   • les coordonnées par défaut [0,0]

     make run     # equals COORDS='0 0'

   • toutes coordonnées données

     COORDS='5 6' make run

Les Makefiles peuvent parfois être extrêmement utiles. Plus le projet est grand, plus les avantages sont importants. Mais même avec mon plus petit projet C ++, comme vous pouvez le voir sur les exemples, vous évitez beaucoup de maux de tête.

makeest assez fiable disponible. Si vous distribuez votre projet avec un makefile, les utilisateurs auront une référence simple pour savoir comment réaliser des tâches de la même manière que vous. Le makefilepeut être plus qu'une simple compilation.

Prenez un projet qui ne nécessite pas de compilation, par exemple. Je me souviens avoir travaillé sur un projet Python qui avait une commande make pour effacer tous les .pycfichiers, une commande make pour exécuter les tests, une pour télécharger une copie des données statiques depuis le serveur de développement, etc.