Re: Makefile : Target-specific Variables

pour info :


pour parer à une partie des pbs ci dessous, voici ce que j'ai fait :

http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/makefil
e-generic.mk?view=markup&pathrev=256 ( https://urlpetite.fr/sg8 )

servez-vous, c'est domaine-public ! :-)



In article
<fantome.forums.tDeContes-279A08.22432816072021@news.free.fr>,
 Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/makefile-Main.mk?view=markup&pathrev=232 ( https://urlpetite.fr/6tz )
 
 
 

il y a autre chose d'assez basique qui manque amha : le traitement de la
casse.
je pense que pour moi les 3 classiques suffiraient
("min", "MAJ", "Maj Au Début").

c'est très imparfait, il s'agit de faire une table de hachage
(y a-t-il une traduction pour "hashed map" plutôt que "hash table" ?)
dans laquelle on doit faire une entrée pour chaque mot à convertir.

 
 
 

3

 
l 139-147
 

je n'ai pas trouvé mieux que de faire des variables de noms différents
pour chaque cas de figure
(avec au minimum distclean qui dépend de clean),
avec un $(or ) pour détecter dans quel cas de figure on est.
 
est il possible de faire mieux que ça ?

et il me reste un pb non résolu dans le cas où on passe plusieurs cibles
à make dans la même commande, puisque dans ce cas la cible examples est
exécutée qu'une seule fois,
donc il faudrait trouver le moyen
- soit de passer plusieurs cibles en même temps,
- soit, si on fait des cibles intermédiaires différentes, de ne pas
exécuter trop de choses, par ex plusieurs fois la même cible, par ex si
on demande à la fois clean et distclean.

 
 
 

4

 
suggestion d'amélioration :
 

si l'interprétation des définitions de variables/cible et des prerequis
était faite pendant la 2eme phase de lecture du Makefile, comme les
Recettes, plutôt que pendant la 1ere phase,
- on pourrais faire énormément plus de choses,
- en plus, ça éviterais la spécificité de la 2nd expansion, puisque ça
donnerais la même fonctionnalité naturellement.

 
 
mais je suppose que si ça n'a pas été fait jusqu'à maintenant, c'est
parce que qqch d'important m'a échappé ?

 
depuis la dernière fois, je ne vois tjr pas quoi ...
 
 
mais je peux faire une suggestion intermédiaire,
à laquelle je ne vois que des inconvénients et aucun avantage par
rapport à la 1ere, par ex elle ne résoudrait pas le point 3,
mais qui serait peut être plus acceptable pour les développeurs :
 
il suffirait de rendre disponible les variables automatiques dans les
définitions des variables/cible.
 
cette fois ci, je ne vois vraiment pas ce qu'il peut y avoir comme
inconvénient à ça.

et j'ai trouvé comment le faire !

bon là je ne l'ai fait que pour $@
parce que comme je n'ai pas besoin d'autre chose, et que je n'ai pas la
certitude que qqn s'intéressera à ce que je fais, je ne vois pas
l'intérêt de m'embêter avec le reste,
mais je pense que ça devrais être possible de le faire pour toutes les
variables automatiques.

 
 
- l 226-228 :
ça permettrais de factoriser (à condition de pouvoir traiter la casse)

fait !

 
- l 259 :
j'ai un sub-make,
PEERS peut être construit de façon dynamique.
sans aucune de ces 2 suggestions, je ne vois pas comment éviter le
sub-make,
alors qu'avec c'est assez facile.

pas fait.

je ne me souviens plus très bien de ce que j'avais en tête à ce moment
là.
c'est peut-être à cause d'un pb lié à gnat, qui nécessite qu'on change
de répertoire,
et/ou peut-être à cause du faut qu'on ne peut pas exécuter plusieurs
fois la même cible.

pas grave, cette partie est bien factorisée, et fonctionne bien.
je ne sais plus pourquoi il faut éviter les sub-make autant que possible.

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/