L'utilisation directe de Make est-elle considérée comme obsolète?
J'ai donc rencontré de nombreux commentaires/articles/etc. concernant la création directe de fichiers makefile et la façon dont c'est une chose stupide à faire en 2015. Je connais des outils tels que CMake et j'utilise CMake assez souvent. Le fait est que CMake crée simplement le Makefile pour vous et aide à éliminer l'ennui de le faire vous-même. Bien sûr, il ajoute beaucoup d'autres fonctionnalités intéressantes ... mais c'est toujours un Makefile à la fin.
Ma question est donc la suivante: le discours "obsolète" concernant make fait-il référence à l'ensemble de l'utilitaire Make, ou simplement l'idée d'écrire manuellement vos propres Makefiles? Je n'utilise pas du tout IDE pour le développement C/C++ (juste des emacs), donc j'ai toujours écrit des Makefiles.
Si Make est considéré comme obsolète, que devrait utiliser un développeur C/C++ pour créer de petits projets personnels?
La grande différence est que CMake est un système de méta-construction multiplateforme. Un seul projet CMake peut produire le makefile Unix/Linux habituel, un projet Visual Studio pour Windows, un projet XCode pour Mac et presque tout autre système de construction non méta que vous voudrez peut-être utiliser ou prendre en charge.
Je ne dirais pas que l'utilisation de make directement ou même l'édition manuelle de makefiles est "obsolète", mais ce sont des choses que vous ne devriez probablement pas faire à moins que vous ne travailliez sur des trucs Unix/Linux qui n'auront pas besoin d'être portés sur Windows, un peu comme la façon dont vous ne doit pas modifier directement les fichiers de projet Visual Studio si vous souhaitez les porter sur un système autre que Windows. Si vous êtes intéressé par la portabilité, cela vaut la peine d'apprendre un système de méta-construction comme Scons ou CMake.
make est-il vraiment obsolète?
Je ne pense pas. En fin de compte, make est encore assez puissant pour fournir toutes les fonctionnalités souhaitées, comme la compilation conditionnelle de sources modifiées et similaires. Dire que make était obsolète reviendrait à dire que l'écriture de scripts de l'éditeur de liens personnalisés était obsolète.
Mais ce que make ne fournit pas, ce sont des fonctionnalités étendues et des bibliothèques de stockage pour plus de confort, telles que la génération d'en-têtes paramétriques, un cadre de test intégré ou même simplement des bibliothèques conditionnelles en général.
D'un autre côté, CMake est directement adapté à la génération de bibliothèques ELF génériques et d'exécutables. Chaque fois que vous vous écartez de ces procédures prédéfinies, vous devez commencer à pirater CMake comme vous le faisiez auparavant pour pirater vos propres Makefiles.
Étant donné que vous pouvez créer bien plus en C++ que votre application moyenne pour un système qui connaît les chargeurs ELF, CMake n'est certainement pas adapté à tous les scénarios. Cependant, si vous travaillez dans un environnement aussi standardisé, CMake ou tout autre de ces cadres de générateur de script modernes sont certainement vos meilleurs amis.
Cela dépend toujours de la spécialisation de votre application et de l'adéquation de la structure du cadre CMake avec votre flux de travail.
Il était une fois des langues de haut niveau, ce n'était qu'une idée. Les gens ont essayé d'implémenter des compilateurs. À l'époque, il y avait de graves limitations matérielles - il n'y avait pas d'outils graphiques, donc le "texte brut" a fini par être utilisé pour le format de fichier d'entrée; les ordinateurs avaient généralement une très petite quantité de RAM donc le code source devait être divisé en morceaux et le compilateur était divisé en utilitaires séparés (pré-processeur, compilateur, assembleur, éditeur de liens); les CPU étaient lent et coûteux, vous ne pouvez donc pas faire d'optimisations coûteuses, etc.
Bien sûr, avec de nombreux fichiers source et de nombreux utilitaires utilisés pour créer de nombreux fichiers objets, il est difficile de créer quoi que ce soit manuellement. Pour contourner les défauts de conception des outils (causés par un matériel très limité), les gens ont naturellement commencé à écrire des scripts pour éliminer certains tracas.
Malheureusement, les scripts étaient maladroits et désordonnés. Pour contourner les problèmes de scripts (qui consistaient à contourner les défauts de conception des outils causés par un matériel limité), les utilisateurs ont finalement inventé des utilitaires pour faciliter les choses, comme make.
Toutefois; les makefiles sont maladroits et désordonnés. Pour contourner les problèmes avec les makefiles (qui étaient une solution de contournement pour les défauts de conception des outils causés par un matériel limité), les gens ont commencé à expérimenter avec les makefiles générés automatiquement; commencer par des choses comme obtenir le compilateur pour générer des dépendances; et menant à des outils comme auto-conf et cmake.
C'est là que nous en sommes maintenant: des solutions pour des solutions pour une solution pour les défauts de conception des outils causés par un matériel limité.
Je m'attends à ce qu'à la fin du siècle, il y ait quelques couches supplémentaires de "solutions de rechange pour les solutions de rechange" au-dessus de la pile existante. Ironiquement, les limitations matérielles sévères qui ont causé tout cela ont disparu il y a plusieurs décennies et la seule raison pour laquelle nous utilisons encore un tel désordre archaïque est "c'est ainsi que cela a toujours été fait".
make (l'outil ou son utilisation directe via un Makefile) n'est pas obsolète, en particulier pour les "petits projets personnels" comme vous l'utilisez pour.
Bien sûr, vous pouvez également l'utiliser pour des projets plus importants, y compris ceux ciblés pour plusieurs plates-formes. Avec variables spécifiques à la cible vous pouvez facilement personnaliser la façon dont vous construisez pour différentes plates-formes. De nos jours, les distributions Linux sont livrées avec des chaînes d'outils de compilation croisée (par exemple mingw-w64 ) afin que vous puissiez créer un package logiciel Windows complet (avec le programme d'installation si vous le souhaitez) à partir de Linux, le tout à partir de votre Makefile.
Des outils comme cmake et qmake peuvent être utiles, mais ils ne sont pas sans problèmes. Ils sont généralement bien pour construire une application elle-même avec toutes les bibliothèques (bien que j'ai toujours eu des problèmes avec qmake pour vérifier correctement les dépendances entre les bibliothèques et les programmes qui les utilisent), mais j'ai toujours du mal avec les contraintes de ces outils lorsque je fais le reste de la (créer des programmes d'installation, générer/installer des fichiers de documentation ou de traduction, faire des choses inhabituelles comme transformer une archive en bibliothèque partagée, etc.). Tout cela peut être fait dans make, bien que des choses comme suivi des dépendances peuvent nécessiter un peu d'effort.
Les IDE tels que Qt Creator et Eclipse peuvent également importer des projets basés sur Makefile, vous pouvez donc partager avec les développeurs utilisant IDE. Je pense que Qt Creator IDE est excellent en tant qu'IDE C++, mais après avoir passé un certain temps à devenir plus efficace avec Emacs, et puisque je fais plus de développement Ada, je me retrouve à préférer Emacs pour tout. Pour revenir à la question sur make, en tant qu'étape post-lien dans mon Makefile, je mets à jour mon fichier TAGS (pour navigation par symboles dans Emacs), chargé avec M-x visit-tags-table:
find $(SRC_DIR) $(TEST_DIR) -regex ".*\.[ch]\(pp\)?" -print | etags -
Ou pour le développement d'Ada:
find $(SRC_DIR) $(TEST_DIR) -name "*.ad?" -print | etags -
Cette réponse complète la réponse @lxrec.
Les Makefiles peuvent être utilisés pour beaucoup de choses, pas seulement pour créer un programme/bibliothèque à partir du code source. Les systèmes de construction tels que CMake ou autotools sont conçus pour prendre du code et le construire de manière à s'adapter à la plate-forme de l'utilisateur (c'est-à-dire trouver des bibliothèques ou spécifier des options de compilation correctes). Vous pouvez par exemple avoir un makefile qui aide à automatiser certaines tâches de publication, telles que: construire un fichier Zip contenant du code avec la version dérivée de git; exécuter des tests sur votre code; télécharger ledit fichier Zip sur un service d'hébergement. Certains systèmes de construction (comme automake) peuvent fournir un moyen facile de le faire, d'autres non.
Cela ne veut pas dire que vous devez utiliser des makefiles pour cela, vous pouvez utiliser un langage de script (Shell, python etc.) pour de telles tâches.
Je ne pense pas que les Makefile - écrits par l'homme soient obsolètes, surtout quand:
- en utilisant POSIX make, qui vous donne un portable
Makefile - ou en utilisant GNU make 4, qui vous offre de nombreuses fonctionnalités très intéressantes, en particulier la scriptabilité GUILE, qui permet de coder efficacement les fonctionnalités sophistiquées fournies par les générateurs
Makefile(je crois que le les fonctionnalités des outils automatiques ou de Cmake pourraient être facilement écrites par la personnalisation de Guile de GNU make). Bien sûr, le prix à payer est de demander GNU make 4 (pas un gros problème, à mon humble avis).
Les makefiles ne sont pas obsolètes, de la même manière que les fichiers texte ne sont pas obsolètes. Stocker toutes les données en texte brut n'est pas toujours la bonne façon de faire les choses, mais si tout ce que vous voulez est une liste de Todo, un fichier texte brut est parfait. Pour quelque chose de plus compliqué, vous voudrez peut-être un format plus compliqué comme Markdown ou XML ou un format binaire personnalisé ou quoi que ce soit entre les deux, mais pour les cas simples, le texte brut fonctionne très bien.
De même, si tout ce que vous voulez, c'est un moyen d'éviter d'écrire g++ -g src/*.c -o blah -W -Wall -Werror && ./blah tout le temps, un Makefile manuscrit est parfait!
Si vous voulez créer quelque chose de très portable, où vous n'avez pas à gérer vous-même cette portabilité, vous voulez probablement quelque chose comme Autotools pour générer le Makefile qui vous convient. Autotools détectera les fonctionnalités prises en charge par diverses plates-formes. Un programme écrit en standard C89 construit avec Autotools se compilera pratiquement partout.