Forum Programmation.c Un exemple de makefile

Posté par  .
Étiquettes : aucune
0
12
jan.
2006
Je cherche un code source (en C) assez conséquent pour être séparé en différents modules, ces modules seraient décomposés en différent répertoire, où chaque répertoires comporterait un fichier makefile différent. Car je n'ai pas trouvé de doc expliquant la meilleure démarche pour utiliser les makefile dans ce genre d'utilisation (les hello world j'en ai à la pelle par contre), et je ne suis jamais contre relire le code d'autre personne (surtout si il est bien fait) .

Quelle application me conseillez vous de télécharger ?

  • # Juste pour parler...

    Posté par  . Évalué à 1.

    Les gros projets libre utilisent souvent des trucs genre autoconf/automake, donc pour ça qu'il y a pas trop d'exemples avec des Makefile (non généré) dans plusieurs répertoires.

  • # le plus beau

    Posté par  . Évalué à 2.

    et peut etre un des plus gros est le kernel linux.
    www.kernel.org
    il y a des makefile partout....

    • [^] # Re: le plus beau

      Posté par  . Évalué à 1.

      En effet, je l'ai télécharger je crois que la je tiens mon exemple.

      Je pense que pour l'instant je vais développer avec des makefiles fait disons à l'arache et après passer au autoconf faisons place au progrès.

      A moins bien sur qu'il y est un argument qui vaille la peine que reste avec des makefile normaux.

  • # info

    Posté par  . Évalué à 1.

    Essaie "info make", la documentation est particulièrement bien faite.

  • # Cscene

    Posté par  . Évalué à 3.

    Sur ce site il y a un article sympa qui explique comment séparer un programme C en plusieurs fichiers et comment utiliser make pour le compiler :
    http://www.gmonline.demon.co.uk/cscene/CS2/CS2-10.html

    Sinon, passer à autoconf/automake après me semble effectivement être une bonne idée. Quelques liens pêle-mêle qui traînent dans mes bookmarks :
    Autoconf Tutorial : http://www.galassi.org/mark//mydocs/autoconf_tutorial_toc.ht(...)
    GNU Autotools bootstrapper : http://bootstrapper.sourceforge.net/index.php?name=tutorial
    Autconf / automake (français) :
    http://www.infres.enst.fr/~dax/polys/configure/
    Autoconf, Automake, and Libtool (livre en ligne) : http://sources.redhat.com/autobook/autobook/autobook_toc.htm(...)

    Bon courage...

  • # Attention aux make récursifs...

    Posté par  . Évalué à 2.

    Pour organiser le processus de compilation d'un projet consistué de plusieurs modules, il faut faire attention a ne pas faire de make recursifs cf. http://www.pcug.org.au/%7Emillerp/rmch/recu-make-cons-harm.h(...) pour plus d'infos à ce sujet.

    Ce que je ne comprends pas, c'est pourquoi, malgré ce papier publié en 1997, qui me semble plutôt convaincant et argumenté, on continue encore à faire des make recursifs... (Je veux dire, à part l'inertie, les "on a toujours fait comme ça"...) L'auteur de l'article se serait-il planté dans les grandes largeurs ? Y a-t-il quelque chose qui m'a échappé et qui invalide son argumentaire ?

    • [^] # Re: Attention aux make récursifs...

      Posté par  . Évalué à 1.

      Très intéressant ce document, mais je n'ai pas compris comment on fait si on veut compiler un module séparément, parceque si j'ai bien compris toutes la compilation est exécutée par un makefile central. (je me base sur l'exemple final)

      Car les fichiers definissant les règles de compilation de chaque module ne comportent alors que des définitions de macro.

      Alors comment est-ce que l'on fait dans ce cas ?

      • [^] # Re: Attention aux make récursifs...

        Posté par  . Évalué à 2.

        En fait, ça fait un moment que je ne l'ai pas lu... et que je n'ai pas touché à make.
        Si tu fais référence à l'exemple du paragraphe 7, il ne peut pas compiler les modules ant ou bee séparément; il recompile la cible "prog" en compilant au besoin ce qui a été listé dans SRC et LIBS. Dans son cas, les "modules" ant et bee sont en fait des séparations au niveau source, mais qui permettent d'obtenir un unique binaire "cible".

        En effet, si tu veux juste obtenir un seul binaire, tu t'en fiches un peu qu'il recompile tel ou tel module (tant qu'il ne fait que le strict minimum, ce qui est aussi le but de la méthode de l'article).

        Si tu entends tes "modules" comme des entités utilisables séparément (ant et bee sont deux exectuables, ou un executable et une bibliothèque, par exemple, et un coup "je veux compiler ant seul", un coup "je veux compiler bee seul"), il faudra une cible par "module".

        Je crois, à ce niveau, que l'incompréhension vient de ce que tu entends par "module" n'est pas la même chose que pour l'auteur de l'article: pour lui, un module est un composant intermédiaire, et il n'y a pas de sens à vouloir compiler tel ou tel module, on ne peut vouloir compiler que la cible - ce qui peut nécessiter de compiler tel ou tel autre module si besoin.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.