Bonsoir,
Il m'est venu une idée à propos des nbuilds ...
Je pense qu'il peut être approprié pour l'utilisateur qui va construire
le nbuild de vouloir l'adapter a ses besoins.
Exemple concrêt: J'ai un paquet (lua) et je prévois de proposer deux
patches :
- readline patch ajoutant la completition avec la touche <tab>
- thread permettant de faire du multithreading
L'utilisateur peut être amené a vouloir que ces patches soient
appliqués ou non. Concrètement, si on fait du copier coller de scripts
dans la console, la completition avec <tab> posera problème. Et si on
n'a pas besoin de faire du multithreading, autant ne pas compiler le
support des threads car cela va ralentir lua.
Partant de ce constat, je pense qu'il faudrait un système de flags (à
la Gentoo). Je vois d'ici une objection : ce serait compliqué de
maintenir ces flags pour toute une distribution. Je suis d'accord.
je propose donc que ces flags ne soient pas communs à toutes les
applications mais spécifiques aux nbuilds.
On pourrait aussi imaginer avoir non seulement des flags boolens mais
aussi des flags avec clef:valeur. par exemple (fictif), lua permettrait
à la compilation de choisir de manière numérique la valeur maximale
d'un nombre. on aurait ainsi le flag 'maxnumber' auquel on donnerait la
valeur '1000000' par exemple.
Concrètement en ligne de commande Ncooker, on aurait une option --flags
qui serait suivie d'une liste de flags séparée par des espaces et
précédés chacun d'un + ou d'un - .Pour les flags clef/valeur, on aurait
un = suivi de la valeur du flag.
Par exemple : Ncooker build --flags '+threads -readline maxnumber=10000'
Il faut bien sûr que le paquet docuimente les flags qu'il propose. Cela
devrait être disponible avec une commande Ncooker
Si un jour on arrive avec un Ncooker avec une gestion des dépendances,
il pourrait ête intéressant de définir de tels flags non seulement pour
le paquet qu'on demande de compiler, mais aussi pour tous les paquets
qui en dépendent. Il faut alors différencier les flags destinés a un
paquet ou a un autre paquet.
Dans un contexte avec de multiples dépendances, on pourrait imaginer
qu'un flag se décrirait ainsi : (crochet = optionnel ; | = ou)
[nom_du_paquet:][+|-]flag[=valeur]
Ces flags pourraient se donner soit sur la ligne de commande, soit dans
une variable d'un fichier de conf ... a voir.
Bon, vous remarquerez que j'ai mis le nom du paquet comme étant
optionnel. La raison est simple : Si un paquet dispose d'un flag kde
(par exemple) et qu'il dépend d'un paquet disposant du flag kde ...
etc. Au lieu de définir de manière fastidieuse :
soft1:+kde soft2:+kde soft3:+kde ...
il suffirait de:
+kde
Alors, bien sûr les flags sont suceptibles d'être différents pour
chaque paquet. Cependant, on peut raisonablement penser qu'un flag
'kde' aura la même signification d'un paquet à l'autre, non ?
Et si ce n'est pas le cas, il faudra faire attention avant.
Bon, voila, j'ai exprimé mon idée ... qu'en pensez-vous ?
Sinon, a défaut d'un tel système (si vous nen voulez pas) je pense
qu'il serait intéressant de pouvoir donner des paramètres au script
build. Car concrètement, dans mon fichier build, j'ai le choix
d'appliquer deux patches ... et j'ai envie de pouvoir laisser le choix
des patches a appliquer.
Mildred
--
Mildred <xmpp:[EMAIL PROTECTED]> <http://mildred632.free.fr/>
Clef GPG : <hkp://pgp.mit.edu> ou <http://mildred632.free.fr/gpg_key>
Fingerprint : 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 [9A7D 2E2B]
--
Mildred <xmpp:[EMAIL PROTECTED]> <http://mildred632.free.fr/>
Clef GPG : <hkp://pgp.mit.edu> ou <http://mildred632.free.fr/gpg_key>
Fingerprint : 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 [9A7D 2E2B]
_______________________________________________
Nasgaia-dev mailing list
[email protected]
https://mail.gna.org/listinfo/nasgaia-dev
