Forum Programmation.autre Makefile récursifs et variable

Posté par enclair le 12 septembre 2010 à 21:19.

Étiquettes : aucune

sept.

2010

Bonjour,

J'ai un code source avec plusieurs répertoires imbriqués. Je voudrais lancer le Makefile à la racine, qui appelle les sous Makefiles etc...
A chaque étape, un sous Makefile compile les .c de son répertoire, il garde ensuite en mémoire les .o dans une variable et le Makefile à la racine fait l'édition de lien à partir de ces fichiers objets.

Le problème, c'est que je n'arrive pas à garder en mémoire les fichiers objets. Par exemple, j'ai la structure récursive suivante :



makefile1/

+--------- Makefile

+--------- makefile2/

           +--------- Makefile

           +--------- makefile3/

                      +--------- Makefile

(3 répertoires imbriqués, chacun à un makefile).

Le premier contient :



export MYVAR = makefile1



all:

	@echo "makefile1 (1) MYVAR = $(MYVAR)"

	cd makefile2; make

	@echo "makefile1 (2) MYVAR = $(MYVAR)"

Le deuxième :



MYVAR += makefile2 



all:

	@echo "makefile2 (1) MYVAR = $(MYVAR)"

	cd makefile3; make

	@echo "makefile2 (2) MYVAR = $(MYVAR)"

Le troisième :



MYVAR += makefile3 



all:

	@echo "makefile3 MYVAR = $(MYVAR)"

Si je lance le premier, je vais obtenir :

makefile1 (1) MYVAR = makefile1
makefile2 (1) MYVAR = makefile1 makefile2
makefile3 MYVAR = makefile1 makefile2 makefile3
makefile2 (2) MYVAR = makefile1 makefile2
makefile1 (2) MYVAR = makefile1

Et moi, je voudrais obtenir :

makefile1 (1) MYVAR = makefile1
makefile2 (1) MYVAR = makefile1 makefile2
makefile3 MYVAR = makefile1 makefile2 makefile3
makefile2 (2) MYVAR = makefile1 makefile2 makefile3
makefile1 (2) MYVAR = makefile1 makefile2 makefile3

Comment je peux faire ?

# c'est tout bête et comme en shell

Posté par fearan le 13 septembre 2010 à 00:17. Évalué à 4.

les variables ne vont que dans un sens ^^
plusieurs solutions s'offrent à toi :) (enfin de mon point de vue, peut être que des gens plus experts en auront d'autres)

Le plus 'standard' (de mon point de vue, et comme solution la moins 'crade' de celles que je propose), avoir un répertoire de build, et envoyer tous les .o dedans, ensuite l'édition de lien se fera à partir de tous les .o du répertoire destination, ça a le mérite d'être simple.
une solution pour ce répertoire, c'est avoir la variable EXEMPLE=obj puis ../obj puis ../../obj ...

une autre solution, se servir d'un fichier dans lequel tu enregistre le nom de tous les fichier (leur chemin relatif) dans un ficher (par exemple /tmp/lstObj.txt) et lire le fichier au final.

enfin utiliser find après la compilation des .o
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
- [^] # Re: c'est tout bête et comme en shell
  
  Posté par Xaapyks le 13 septembre 2010 à 03:05. Évalué à 2.
  
  SI j'en crois la doc, oui c'est comme le shell : export var= xxx Je sais pas si c'est exactement ce que tu cherches.
  (non testé)
  
  PS : on appelle pas un sous make comme ça, mais avec $(MAKE)
  - [^] # Re: c'est tout bête et comme en shell
    
    Posté par Johands le 13 septembre 2010 à 15:39. Évalué à 3.
    
    ... pour reprendre la bonne remarque du P.S. précédent le manuel de (gnu) make incite effectivement à appeler les sous-make avec $(MAKE) -C monRépertoire maCommande.
    
    Pour le pourquoi du comment, \google{manual gnu make} is your friend.
- [^] # Re: c'est tout bête et comme en shell
  
  Posté par enclair le 13 septembre 2010 à 21:10. Évalué à 1.
  
  Merci, j'ai utilisé la première solution + find (puisque mon répertoire où je place mes fichiers objets suit la structure des sources).
  
  Je regarderai le papier ci-dessous plus tard.
# make récursif = pas bien

Posté par gaaaaaAab le 13 septembre 2010 à 15:36. Évalué à 3.

du temps ou je faisais beaucoup de makefile, j'étais tombé là dessus :

http://miller.emu.id.au/pmiller/books/rmch/

pour les gros projets, les make récursifs coûtent très chers puisqu'ils faut forker un make pour chaque répertoire.

C'est en fait possible (et pas beaucoup plus compliqué) d'avoir une seul makefile pour les gouverner tous, et dans les ténèbres, les lier.
- [^] # Re: make récursif = pas bien
  
  Posté par Johands le 13 septembre 2010 à 15:44. Évalué à 2.
  
  On est pas vendredi mais qui s'en soucis encore des coûts d'un fork de `make` et de la surcharge CPU/RAM associée, sachant la puissance des machines d'aujourd'hui ?
  
  L'article date de 1997 et depuis ce temps, Sun a démocratisé Java et MS a inventé Vista ...
  - [^] # Re: make récursif = pas bien
    
    Posté par gaaaaaAab le 13 septembre 2010 à 16:47. Évalué à 6.
    
    l'augmentation des performances du hardware, c'est souvent utilisé comme prétexte pour gérer les ressources n'importe comment ...
    
    sur un projet ici, en dehors de pondre des makefile récursifs, le générateur maison de makefile était un peu trop frileux et recompilait pleins de répertoires pour rien.
    
    Et ben mine de rien, gagner 20 minutes sur une compile de 40, c'est pas mal.
    
    Comme je le précisais dans mon commentaire précédent, c'est intéressant de se pencher sur la question pour les gros projets avec une arborescence conséquente.
    
    Sur les petits projets, l'intérêt est effectivement très faible.
    - [^] # Re: make récursif = pas bien
      
      Posté par Johands le 13 septembre 2010 à 19:29. Évalué à 2.
      
      Merci à Armand pour son commentaire sur l'arbre des dépendances. Je vais tenter de jeter un coup d'œil à l'article (oui frappez moi, je trolle sur des sujets que je ne lis pas :p).
      
      Et concernant l'anecdote du projet maison et des 20 minutes de gagner lors de la compilation, je me demandais : mais quel générateur maison ? (si ce n'est pas indiscret) Un truc encore plus moche et plus lent que auto{tools:make} ?
      - [^] # Re: make récursif = pas bien
        
        Posté par gaaaaaAab le 13 septembre 2010 à 20:36. Évalué à 2.
        
        je trolle sur des sujets que je ne lis pas :p
        c'est un peu le principe, non ? :)
        cela dit, mon commentaire n'était pas complètement pertinent non plus semble-t-il
        
        mais quel générateur maison ?
        
        un outil complément interne. Il s'agit d'un script en python qui gère les dépendances entre modules (avec une vérification sommaire de la compatibilité des versions des différents modules). Les makefile générés par ce script stockent les produits de la compilation dans des sous répertoires spécifiques à chaque architecture (pour éviter d'avoir à tout recompiler à chaque fois qu'on change de cible). Et ça, c'est quand même intéressant vu qu'on compile sur HP-UX sur Itanium (et autre chose, mais je ne sais plus quoi), Solaris 9 sur sparc, solaris 10 sur sparc/x86, Linux sur x86 et quelques vieilleries sur AIX.
        
        Cela dit, comme tout outil développé en interne et peu maintenu, il amène son lot de contraintes :)
        
        Mon problème de perf venait du fait que pour chaque sous répertoire de niveau n, make était lancé n-1 fois. Évidemment, n-2 fois, il ne faisait pas grand chose ... à part recopîer tous les produits utiles de la compilations dans le sous répertoire de l'architecture du moment ... arg ! :D
        
        L'exemple que je donne ne portait pas sur les makefile récursifs (vu qu'ils le sont toujours), mais sur ton affirmation selon laquelle l'augmentation des perfs des machines permettrait de s'abstenir de se pencher sur les perfs de sa chaine de compil.
        C'est parfois vrai, parfois pas :)
    - [^] # Re: make récursif = pas bien
      
      Posté par bubar🦥 (site web personnel) le 14 septembre 2010 à 12:03. Évalué à 3.
      
      >l'augmentation des performances du hardware, c'est souvent utilisé comme prétexte pour gérer les ressources n'importe comment ...
      c'est beau, ça fonctionne aussi dans l'autre sens !
      gérer les ressources n'importe c'est souvent utilisé comme pretexte pour avoir une augmentation des performances du hardware
      - [^] # Re: make récursif = pas bien
        
        Posté par Johands le 14 septembre 2010 à 13:56. Évalué à 4.
        
        Moi franchement ça ne me dérange pas qu'Intel et Windows complote pour l'obsolescence du PC de Mme Michu ou des serveurs de Mr Dupont.
        
        Grâce à ça, les bi-cœurs sont déjà démocratisés et bientôt on pourra avoir des octo-cœurs ou des mini HPC GPGPU/OpenCL sur nos bureaux pour trois francs six sous. Plus la peine de s'inscrire à l'ENS et de décrocher une thèse au CEA pour pouvoir faire joujou avec des "grosses" machines (comprendre grosse, relativement aux demandes de Mme Michu).
        
        [^] # Re: make récursif = pas bien
        
        Posté par gaaaaaAab le 14 septembre 2010 à 14:36. Évalué à 2.
        
        Intel et Windows
        
        pour une fois, je pensais plutôt aux développeurs qu'aux fondeurs/éditeurs d'OS :)
  - [^] # Re: make récursif = pas bien
    
    Posté par Amand Tihon (site web personnel) le 13 septembre 2010 à 17:10. Évalué à 5.
    
    Le véritable problème mis en avant par le papier, c'est n'est pas le coût des appels à fork() mais le fait que ces appels récursifs cassent complètement l'abre des dépendances que make pourrait construire et gérer tout seul.
    
    Ce papier vaut vraiment la peine d'être lu, et il contient des exemples très explicites de problèmes typiques causés par les appels récursifs de make.
    - [^] # Re: make récursif = pas bien
      
      Posté par gaaaaaAab le 13 septembre 2010 à 18:35. Évalué à 2.
      
      merci pour cette utile précision.
      Je l'ai lu il y a lonnngtemps, et j'en avais principalement retenu la conclusion (éviter les make récursifs).

Suivre le flux des commentaires

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