Téléchargé 39 fois
Vote des utilisateurs
3
0
Détails
Licence : GPL
Mise en ligne le 20 janvier 2017
Plate-forme :
Linux
Langue : Français
Référencé dans
Navigation
Makefile générique
Makefile générique
Makefile générique
Makefile idéal pour la construction rapide d'un exécutable sans se préoccuper de la gestion parfois complexe du Makefile : la fainéantise n'est plus une excuse.
Makefile idéal pour la construction rapide d'un exécutable sans se préoccuper de la gestion parfois complexe du Makefile : la fainéantise n'est plus une excuse.
Nos ressources disponibles
**********************
* Utilisation simple *
**********************
make va automatiquement gérer les dépendances entre les fichiers sources et créer un exécutable dans le répertoire Debug. Cet exécutable portera le nom du répertoire qui contient le Makefile.
Exemple:
***********************
* Utilisation avancée *
***********************
Le fichier Makefile est commenté. Les options et variables qui dictent son comportement sont décrites lors de leur déclaration.
Ce Makefile est idéal dans le cas d'un petit projet qui ne crée qu'un exécutable, qui peut utiliser une bibliothèque de commodité et d'autres bibliothèques gérées par pkg-config.
Deux types principaux de build sont supportés :
Dans chaque cas, il est possible d'ajouter les options pour le profilage et le support des pthreads.
Le build peut se faire en mode SILENT, c'est-à-dire que les commandes ne sont pas affichées mais une indication (comme dans l'exemple ci-dessus) de ce qui est fait. Cette option est facilement débrayable soit en modifiant le Makefile, soit par la ligne de commande : make SILENT=0 (cf les commentaires dans le Makefile).
Remarques
N'hésitez pas à laisser un commentaire, des propositions d'améliorations ou de correction. N'hésitez pas non plus si vous avez la moindre question à propos de cette contribution.
K.
* Utilisation simple *
**********************
- décompresser l'archive
- renommer le répertoire ProjetMakefile
- placer les sources dans le répertoire src
- lancer make
make va automatiquement gérer les dépendances entre les fichiers sources et créer un exécutable dans le répertoire Debug. Cet exécutable portera le nom du répertoire qui contient le Makefile.
Exemple:
Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | ~/Projets> unzip ProjetMakefile.zip ~/Projets> mv ProjetMakefile test ~/Projets> cd test ~/Projets/test> cat > src/main.c #include > > int main() > { > puts("Hello world"); > > return 0; > } > EOF ~/Projets/test> make GENDEP libutil/xlog.c GENDEP src/main.c CC src/main.c CC libutil/xlog.c AR libutil.a CCLD Debug/test debug version built ~/Projets/test> ls Debug/ libutil/ license.txt Makefile src/ ~/Projets/test> ./Debug/test Hello world ~/Projets/test> |
* Utilisation avancée *
***********************
Le fichier Makefile est commenté. Les options et variables qui dictent son comportement sont décrites lors de leur déclaration.
Ce Makefile est idéal dans le cas d'un petit projet qui ne crée qu'un exécutable, qui peut utiliser une bibliothèque de commodité et d'autres bibliothèques gérées par pkg-config.
Deux types principaux de build sont supportés :
- Debug : aucune option d'optimisation activée
- Release : options d'optimisation classiques activées
Dans chaque cas, il est possible d'ajouter les options pour le profilage et le support des pthreads.
Le build peut se faire en mode SILENT, c'est-à-dire que les commandes ne sont pas affichées mais une indication (comme dans l'exemple ci-dessus) de ce qui est fait. Cette option est facilement débrayable soit en modifiant le Makefile, soit par la ligne de commande : make SILENT=0 (cf les commentaires dans le Makefile).
Remarques
- par défaut le compilateur utilisé est gcc en mode C99 avec les extensions GNU (builtins et attibutes gcc et fonctions GNU_SOURCE de la glibc). Pour utiliser ce Makefile la version GNU de make est indispensable.
- le template est fourni avec un exemple de bibliothèque de commodité permettant un logging simple (4 niveaux debug/info/warning/error, sortie uniquement vers stderr)
- Ce template n'a pas la prétention d'être universel ou de remplacer d'autres outils comme autoconf et cie. Il a pour seul but de simplifier le prototypage ou la construction de petits projets. Entre autre il n'y a aucune cible install ni aucune vérification de la présence de fonctionnalités ou d'outils.
N'hésitez pas à laisser un commentaire, des propositions d'améliorations ou de correction. N'hésitez pas non plus si vous avez la moindre question à propos de cette contribution.
K.
Bonjour,
C'est intéressant, mais j'en suis à me demander pourquoi on n'utiliserai pas les outils genre autotools ou CMake ?
De plus, il y a aussi l'histoire des bibliothèque type SDL, que je voudrais rajouter. On dirait que je dois changer quatres variables LDFLAGS pour y arriver
Ensuite, j'aurais mis une règle
pour afficher une aide rapide
De plus, ce que j'aime bien, lorsque je fais un projet, c'est avoir une règle qui compresse dans une archive mes fichiers afin de les distribuer (Au lieu de tout faire à la main).
Le parcours du dossier src ne semble pas récursif.
Il manque aussi la règle "all".
Sinon l'idée est bonne
C'est intéressant, mais j'en suis à me demander pourquoi on n'utiliserai pas les outils genre autotools ou CMake ?
De plus, il y a aussi l'histoire des bibliothèque type SDL, que je voudrais rajouter. On dirait que je dois changer quatres variables LDFLAGS pour y arriver
Ensuite, j'aurais mis une règle
make help
De plus, ce que j'aime bien, lorsque je fais un projet, c'est avoir une règle qui compresse dans une archive mes fichiers afin de les distribuer (Au lieu de tout faire à la main).
Le parcours du dossier src ne semble pas récursif.
Il manque aussi la règle "all".
Sinon l'idée est bonne
Je vois, mais pour être un truc qui se veut simple, le Makefile me semblait long .
Sinon, pour la mise à jour, on devrait pouvoir s'arranger. Si cela ne vous ai pas possible à vous, il faudra demander soit à moi et je m'arrangerai, soit peut être à Melem.
Sinon, pour la mise à jour, on devrait pouvoir s'arranger. Si cela ne vous ai pas possible à vous, il faudra demander soit à moi et je m'arrangerai, soit peut être à Melem.
Bonjour,
Ma contribution trouve ses origines dans mes «frustrations» : quelle plaie d'éditer tout le temps un makefile pour faire tout le temps la même chose (et je rajoute une cible pour l'exécutable, et je change quelques options parce que je passe d'une version debug à une version release que je désire profiler, et je reviens en arrière, ...).
Mon idée de base était simplement : Ce serait trop bien de n'avoir qu'à placer mes sources dans un répertoire et tout le reste est automatique : ça me crée un exécutable suivant mon envie en tapant simplement make avec une ou deux variables à changer ou à préciser sur la ligne de commande.
Les autotools ou cmake (scons et cie) sont plus complexes et bien plus puissants. On ne joue pas dans la même cours Ces outils sont vraiment bien adaptés aux projets de moyenne à grande envergure que l'on désire déployer.
Ma contribution s'adresse plus aux petits projets, prototypages rapides, essais et tests divers : un peu l'idéal pour le genre de code que l'on peut-être amené à poster ici par exemple (cela évite des makefiles trop calqués à l'architecture de la machine de développement ou à se retrouver face à des post où l'on précise la ligne de commande pour compiler).
Oui et non
Non car SDL vient aussi (mais je peux me tromper suivant les distributions) avec un support pkg-config. Dans ce cas on peut simplement ajouter le nom du package (sdl en l'occurence sur ma configuration) dans la variable PKGLIST pour ajouter ce qu'il faut aux *FLAGS.
Oui s'il n'y a aucun support pkg-config (ou si pkg-config n'est pas dispo, ...). Je pense que dans ce cas le plus simple est que je rajoute des FLAGS perso ...
Je vais le faire d'ailleurs
Du coup une question (j'avoue que je fénéantise sur le coup) comment puis-je modifier le post et updater le téléchargement proposé ?
Arrg ! Oui une cible help ... un gros manque !!!! Un truc de plus à modifier
Du coup j'aurais pu afficher la cible backup qui fait une archive (très sommaire)
Non aucune récursivité dans les répertoires. C'est une des limites que je me suis imposées. Si on commence à avoir besoin de fonctionnalités de ce genre ou plus avancées il est préférable de se tourner vers les outils que tu mentionnais en début de post (autotools cmake ...). J'ai fait une exception, le répertoire lib. Il existe car j'aime y placer mes «sources» de confort (pour faire du log, pour faire des checks de malloc, pour mes sdd de base type liste, arbre binaire ... les sources que j'ai en stock et que j'utilise ponctuellement pour ne pas réinventer la roue tout le temps).
Le but était de rester simple, relativement complet sans trop ajouter de complexité.
Néanmoins le parcours récursif pourrait-être une bonne idée s'il s'agit uniquement d'architecturer les sources pour éviter d'avoir tout à un endroit, pourquoi pas ... peut-être dans une version ultérieure et l'utilisation de la fonctionnalité vpath ???
On va dire ok à faire si le Makefile est utilisé un peu plus largement
Merci d'avoir pris le temps de jeter un coup d'oeil sur ça ... et pour tes remarques fort constructives
Ma contribution trouve ses origines dans mes «frustrations» : quelle plaie d'éditer tout le temps un makefile pour faire tout le temps la même chose (et je rajoute une cible pour l'exécutable, et je change quelques options parce que je passe d'une version debug à une version release que je désire profiler, et je reviens en arrière, ...).
Mon idée de base était simplement : Ce serait trop bien de n'avoir qu'à placer mes sources dans un répertoire et tout le reste est automatique : ça me crée un exécutable suivant mon envie en tapant simplement make avec une ou deux variables à changer ou à préciser sur la ligne de commande.
Les autotools ou cmake (scons et cie) sont plus complexes et bien plus puissants. On ne joue pas dans la même cours Ces outils sont vraiment bien adaptés aux projets de moyenne à grande envergure que l'on désire déployer.
Ma contribution s'adresse plus aux petits projets, prototypages rapides, essais et tests divers : un peu l'idéal pour le genre de code que l'on peut-être amené à poster ici par exemple (cela évite des makefiles trop calqués à l'architecture de la machine de développement ou à se retrouver face à des post où l'on précise la ligne de commande pour compiler).
Oui et non
Non car SDL vient aussi (mais je peux me tromper suivant les distributions) avec un support pkg-config. Dans ce cas on peut simplement ajouter le nom du package (sdl en l'occurence sur ma configuration) dans la variable PKGLIST pour ajouter ce qu'il faut aux *FLAGS.
Oui s'il n'y a aucun support pkg-config (ou si pkg-config n'est pas dispo, ...). Je pense que dans ce cas le plus simple est que je rajoute des FLAGS perso ...
Je vais le faire d'ailleurs
Du coup une question (j'avoue que je fénéantise sur le coup) comment puis-je modifier le post et updater le téléchargement proposé ?
Arrg ! Oui une cible help ... un gros manque !!!! Un truc de plus à modifier
Du coup j'aurais pu afficher la cible backup qui fait une archive (très sommaire)
Non aucune récursivité dans les répertoires. C'est une des limites que je me suis imposées. Si on commence à avoir besoin de fonctionnalités de ce genre ou plus avancées il est préférable de se tourner vers les outils que tu mentionnais en début de post (autotools cmake ...). J'ai fait une exception, le répertoire lib. Il existe car j'aime y placer mes «sources» de confort (pour faire du log, pour faire des checks de malloc, pour mes sdd de base type liste, arbre binaire ... les sources que j'ai en stock et que j'utilise ponctuellement pour ne pas réinventer la roue tout le temps).
Le but était de rester simple, relativement complet sans trop ajouter de complexité.
Néanmoins le parcours récursif pourrait-être une bonne idée s'il s'agit uniquement d'architecturer les sources pour éviter d'avoir tout à un endroit, pourquoi pas ... peut-être dans une version ultérieure et l'utilisation de la fonctionnalité vpath ???
On va dire ok à faire si le Makefile est utilisé un peu plus largement
Merci d'avoir pris le temps de jeter un coup d'oeil sur ça ... et pour tes remarques fort constructives
Developpez.com décline toute responsabilité quant à l'utilisation des différents éléments téléchargés.