L'utilisation directe de Make est-elle considérée comme obsolète? [fermé]

J'ai donc rencontré de nombreux commentaires / articles / etc. concernant la création directe de makefiles, et comment 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 d'IDE pour le développement C / C ++ (juste des emacs), j'ai donc 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 vers 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.

Est makevraiment dépassé?

Je ne pense pas. En fin de compte, make est toujours assez puissant pour fournir toutes les fonctionnalités souhaitées, comme la compilation conditionnelle de sources modifiées et similaires. Dire makeétait obsolète, reviendrait à dire que l'écriture de scripts de l'éditeur de liens personnalisés était obsolète.

Mais ce que Raw makene 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ête paramétrique, le cadre de test intégré ou même simplement les bibliothèques conditionnelles en général.

D'autre part, CMakeest directement adapté à la génération de bibliothèques et d'exécutables ELF génériques. Chaque fois que vous vous écartez de ces procédures prédéfinies, vous devez commencer à pirater CMakecomme vous le faisiez auparavant pour pirater vos propres Makefiles.

Étant donné que vous pouvez créer beaucoup plus en C ++ que votre application moyenne pour un système qui connaît les chargeurs ELF, CMaken'est certainement pas adapté à tous les scénarios. Cependant, si vous travaillez dans un tel environnement standardisé, CMakeou 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 CMakecadre 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 processeurs étaient lents et coûteux, vous ne pouviez 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, par exemple 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 de rechange pour des solutions de rechange pour une solution de rechange pour les défauts de conception des outils causés par un matériel limité.

Je m'attends à ce que d'ici 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 toujours un tel désordre archaïque est " c'est comme ça que ça 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" tels que vous l'utilisez.

Bien sûr, vous pouvez également l'utiliser pour des projets plus importants, y compris ceux ciblés pour plusieurs plates-formes. Avec des variables spécifiques à une 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 le suivi des dépendances puissent nécessiter un peu d'effort.

Les IDE comme 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 l'IDE Qt Creator 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 la navigation 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-s écrits humains soient obsolètes, surtout quand:

1. en utilisant POSIX make, qui vous donne un portable Makefile
2. 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 fantaisistes fournies par les Makefilegénérateurs (je pense que les fonctionnalités des autotools ou de Cmake pourraient être facilement écrites par la personnalisation Guile de GNU make ). Bien sûr, le prix à payer est d'exiger que GNU fasse 4 (ce n'est pas grave, à 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, c'est une liste Todo, alors un fichier texte brut est très bien. 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 est un moyen d'éviter d'écrire g++ -g src/*.c -o blah -W -Wall -Werror && ./blahtout 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.

si votre projet est simple et contient très peu de fichiers, aucun fichier make n'est nécessaire.

Cependant, lorsque le projet est complexe, utilise de nombreuses zones de mémoire, contient de nombreux fichiers, il est alors nécessaire de placer chaque zone de mémoire au bon endroit dans la mémoire adressable, il est hautement souhaitable de ne pas recompiler chaque fichier chaque fois qu'un changement trivial est fait dans un fichier,

Si vous voulez effacer les anciens fichiers / compiler / lier / installer avec le minimum de tracas et le risque d'erreurs de frappe, le makefile est une véritable aubaine.

Lorsque vous entrez dans le `` monde réel '', les projets ne sont que rarement 1 ou 2 fichiers, mais plutôt des centaines de fichiers. un makefile effectuera toujours les bonnes actions et aucune action inutile (après avoir été débogué) donc vous ne tapez qu'une seule commande simple et le makefile fait tout le travail