J'aimerais penser que c'est une blague mais j'ai l'impression que non.
Alors oui, il faut savoir comment Make marche et il faut donc avoir déjà étudié et créé des Makefiles. Mais une fois passé le stade de l'apprentissage, ne jamais faire ses makefiles à la main dans des projets réels. Utilisez les autotools, CMake, Meson peut-être (ça a la côte et certains disent que c'est l'avenir, à voir...), que sais-je... mais n'écrivez pas des makefiles à la main!
Les bons systèmes de build vous apporteront:
une portabilité automatique sur plein de plateformes.
Ex: sur GIMP, quand on est passé à GExiv2, personne arrivait à le compiler pour Windows. Les dévs de GExiv2 eux-même n'étaient pas sûr si c'était possible puisqu'ils n'avaient pensé qu'aux plateformes Linux jusque là. À l'époque, ils utilisaient un makefile fait à la main justement et c'était la misère. Comme c'était devenu une dépendance majeure pour nous, j'ai porté GExiv2 sur les autotools. Le projet est devenu cross-plateforme instantanément et comme il était écrit de manière générique, il a pu être compilé pour Windows sans se poser de question.
La cross-compilation simple: cross-compiler avec des systèmes de build bien faits est quasi aussi simple qu'une compilation native.
Ex: libmypaint utilisait Scons et c'était aussi terrible (je n'ai jamais vu aucun projet utiliser Scons bien, alors j'ai un mauvais a-priori dessus). Des gens arrivaient apparemment à compiler nativement pour Windows, mais pas à cross-compiler. Au final j'ai aussi porté libmypaint sous autotools et maintenant je le cross-compile en quelques minutes sans me poser de questions.
Un standard: autotools utilise les "cibles" standards de GNU ("install", "uninstall", "clean", etc.). Cela rend la compilation très aisé de divers projets dont la compilation fonctionne toujours pareil. C'est un peu moins bon côté CMake pour lequel il manque certaines cibles, et aussi pour lequel on voit régulièrement des "irrégularités". Mais globalement même CMake, avec le temps, les projets tendent à utiliser les mêmes cibles (un standard de fait se crée).
Les compilations "VPATH": on peut compiler aisément et par défaut depuis un autre répertoire que le répertoire source. Cela permet notamment de créer plusieurs builds à partir d'un même source sans conflits (options différentes, ou des cross-compilations justement, etc.).
Simplification: un makefile qui a toutes les fonctionnalités qu'on veut (multi-plateformes, plein de cibles, gestion de compilation, installation, désinstallation, nettoyage, tests unitaires...), ben c'est compliqué. Faire tout ça à la main serait un temps plein rien que pour débugguer constamment. Donc on délègue au système de build. Cela rend la gestion de projet bien plus simple tout en ayant un build avec plein de fonctionnalités.
Les tests unitaires (make check).
La création de paquets sources (make dist) et leur vérification (make distcheck qui crée le paquet puis recompile et joue les tests unitaires à partir du paquet)!
La gestion avancée de la configuration avant compilation.
J'en passe problablement beaucoup. C'est ce qu'il me vient à l'esprit.
Donc non, pas de makefile basique. À part peut-être pour un projet super simple avec juste quelques fichiers ou un projet temporaire. Et encore...
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Désolé de répondre à coté de la plaque
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Version minimum de CMake. Évalué à 10.
J'aimerais penser que c'est une blague mais j'ai l'impression que non.
Alors oui, il faut savoir comment Make marche et il faut donc avoir déjà étudié et créé des Makefiles. Mais une fois passé le stade de l'apprentissage, ne jamais faire ses makefiles à la main dans des projets réels. Utilisez les autotools, CMake, Meson peut-être (ça a la côte et certains disent que c'est l'avenir, à voir...), que sais-je... mais n'écrivez pas des makefiles à la main!
Les bons systèmes de build vous apporteront:
une portabilité automatique sur plein de plateformes.
Ex: sur GIMP, quand on est passé à GExiv2, personne arrivait à le compiler pour Windows. Les dévs de GExiv2 eux-même n'étaient pas sûr si c'était possible puisqu'ils n'avaient pensé qu'aux plateformes Linux jusque là. À l'époque, ils utilisaient un makefile fait à la main justement et c'était la misère. Comme c'était devenu une dépendance majeure pour nous, j'ai porté GExiv2 sur les autotools. Le projet est devenu cross-plateforme instantanément et comme il était écrit de manière générique, il a pu être compilé pour Windows sans se poser de question.
La cross-compilation simple: cross-compiler avec des systèmes de build bien faits est quasi aussi simple qu'une compilation native.
Ex: libmypaint utilisait Scons et c'était aussi terrible (je n'ai jamais vu aucun projet utiliser Scons bien, alors j'ai un mauvais a-priori dessus). Des gens arrivaient apparemment à compiler nativement pour Windows, mais pas à cross-compiler. Au final j'ai aussi porté libmypaint sous autotools et maintenant je le cross-compile en quelques minutes sans me poser de questions.
Un standard: autotools utilise les "cibles" standards de GNU ("install", "uninstall", "clean", etc.). Cela rend la compilation très aisé de divers projets dont la compilation fonctionne toujours pareil. C'est un peu moins bon côté CMake pour lequel il manque certaines cibles, et aussi pour lequel on voit régulièrement des "irrégularités". Mais globalement même CMake, avec le temps, les projets tendent à utiliser les mêmes cibles (un standard de fait se crée).
Les compilations "VPATH": on peut compiler aisément et par défaut depuis un autre répertoire que le répertoire source. Cela permet notamment de créer plusieurs builds à partir d'un même source sans conflits (options différentes, ou des cross-compilations justement, etc.).
Simplification: un makefile qui a toutes les fonctionnalités qu'on veut (multi-plateformes, plein de cibles, gestion de compilation, installation, désinstallation, nettoyage, tests unitaires...), ben c'est compliqué. Faire tout ça à la main serait un temps plein rien que pour débugguer constamment. Donc on délègue au système de build. Cela rend la gestion de projet bien plus simple tout en ayant un build avec plein de fonctionnalités.
Les tests unitaires (make check).
La création de paquets sources (
make dist) et leur vérification (make distcheckqui crée le paquet puis recompile et joue les tests unitaires à partir du paquet)!La gestion avancée de la configuration avant compilation.
J'en passe problablement beaucoup. C'est ce qu'il me vient à l'esprit.
Donc non, pas de makefile basique. À part peut-être pour un projet super simple avec juste quelques fichiers ou un projet temporaire. Et encore...
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]