1
si j'ai bien compris, les variables/cible
- sont visibles dans les Recettes de toutes les cibles enfants,
- mais pas dans les définitions de variables/cible, ni dans celles des
prerequis, des cibles enfants, puisqu'ils sont interprétés pendant la
1ere phase de lecture du Makefile.
donc au moment de la définition des variables/cible, chaque variable
n'est visible que dans cette cible, ni dans ses parents ni dans ses
enfants,
et ça ne dépend pas non plus de l'ordre dans lequel on écrit ça dans le
Makefile.
est ce que j'ai bien compris ?
2
si j'ai bien compris le point 1, je ne comprend pas cette phrase :
"Pattern-specific variables are searched after any target-specific
variables defined explicitly for that target, and before target-specific
variables defined for the parent target."
ça voudrait dire que "target-specific variables are defined before
target-specific variables defined for the parent target" ?
je trouve que c'est pas très intuitif,
mais de toutes façons ça ne correspond pas Í mon expérience ...
est ce que qqn pourrais m'expliquer, svp ?
(en passant, pourquoi est ce que undefine ne permet pas de mettre
plusieurs noms de variable sur la même ligne,
alors que export le permet ?)
3
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 ?
(en passant, je n'ai pas su dire si GOAL était mieux en variable/cible
ou en variable globale, avez vous un avis ?)
4
en réfléchissant bien, je me suis aperçu que :
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.
il me semble que, contrairement Í d'autres choses que je préférerais
différentes, cette suggestion ne pose pas de pb de compatibilité avec
l'existant.
par exemple, pendant la 2eme phase, le traitement des buts choisis,
- on a besoin, pour les différents calculs Í faire Í ce moment lÍ , de
connaitre :
- les parents par lesquels on est passés pour atteindre la cible Í
traiter,
- tous les enfants de la cible.
- mais on n'a jamais besoin de connaitre tous les parents de la cible.
en conséquence,
les enfants de la cible peuvent être calculés, et le graphe de liens qui
relie les cibles entre elles peut être fait,
pendant la 2eme phase en fonction du besoin, plutÍ´t que pendant la 1ere
phase en totalité.
je n'y vois pas d'inconvénient.
mais je suppose que si ça n'a pas été fait jusqu'Í maintenant, c'est
parce que qqch d'important m'a échappé ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Thomas
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%6 ( https://urlpetite.fr/sg8 ) servez-vous, c'est domaine-public ! :-) In article , Thomas wrote:
http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/makefile-Main.mk?view=markup&pathrev#2 ( 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/
pour info :
pour parer Í une partie des pbs ci dessous, voici ce que j'ai fait :
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.
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%6 ( https://urlpetite.fr/sg8 ) servez-vous, c'est domaine-public ! :-) In article , Thomas wrote:
http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/makefile-Main.mk?view=markup&pathrev#2 ( 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/
