Le Lundi 11 Juillet 2005 17:39, Richard Gill a écrit :
> do_static servait effecivement pour la construction non pas du devkit
> mais du système temporaire qui permettait celle du devkit (toujours là
> ? :)).
> Avec ngalfs (ou ngadkm) cela ne sert plus a rien car on a une appli
> spécialisée pour la construction du système temporaire. Par contre,
> comme je n'ai pas retourhcé une LFS depuis un moment, il faut que je
> vérifie si on n'aurait pas besoin de faire deux "passes" pour avoir un
> devkit fonctionnel. Je vous tiens au courant, mais pour moi, plus de
> do_static().
Ok, donc on peut enlever cette fonction.
> > La troisième permet de lancer une vérification de la compilation. Cette
> > fonctionnalité n'est pas présente dans tous les makefiles, mais
> > lorsqu'elle l'est, un simple «make check» permet de lancer une série de
> > tests pour valider que l'application s'est compilée correctement. C'est
> > particulièrement important pour les librairies de base du système.
>
> attention, pour faire les tests, il faut un minimum d'applis
> spécialisées pour les tests, qui ne servent pas autrement (dejagnu,
> expect), donc surement à rendre optionnel (le lancement, pas la
> fonction, j'ai déjà lu la suite :-))
L'appel à cette fonction serait effectivement optionnel. Son exécution serait
demandé grâce à une option de la commande build, ou à défaut selon la valeur
d'une variable dans le fichier Ncooker.conf.
> > - do_config() : S'il n'y a pas de fonction do_config() dans le fichier
> > build, Ncooker recherche un script ./configure exécutable. S'il le trouve
> > il l'exécute. Ok, mais avec quelles options par défaut ? :-) Ici, il
> > n'est pas possible de choisir des options par défaut qui soient vraiment
> > «passe-partout» ... Qui plus est, je me souviens que quelqu'un avait déjà
> > émis le souhait de pouvoir savoir qu'elles sont les options de
> > ./configure utilisées par défaut dans les nbuilds. Je propose une
> > solution pour répondre aux deux problèmes en même temps : utiliser une
> > variable NPKG_CONFIG_OPTIONS dans le fichier «infos» du nbuild. Par
> > exemple :
> >
> > NPKG_CONFIG_OPTIONS="--prefix=/usr --with-ssl"
>
> C'est là que je trouve ça tordu. Quel intérêt à mettre un comportement
> par défaut dans le "infos" plutot que de mettre une fonction
> do_config() dans le build, sous prétexte que le "build" est optionnel.
> Je trouve que "infos" donne desinfos sur le paquet, "build" permet de
> le compiler, c'est bien quand c'est séparé, c'est clair.
Le fichier infos ne contiendrait pas le comportement par défaut que doit
adopter Ncooker pour la fonction do_config(). Aucun comportement par défaut
ne figure dans le fichier infos. Ces comportements sont définis directement
dans la commande build de Ncooker (ou plutôt un sous-module de la commande
build). Ce que contiendrait le fichier infos, lui, ce serait uniquement la
liste des options que doit utiliser la fonction do_config() par défaut de
Ncooker lorsqu'elle lance le script ./configure.
Ça pourrait ressembler à ça :
# Fonction do_config() par défaut de Ncooker
do_config() {
if [ -x configure ]; then
CONFIG_OPTIONs=`récupération des options à passer au
script ./configure dans le fichier infos`
./configure $CONFIG_OPTIONS <options passées à --config-options>
}
le fichier infos XML pourrait contenir une balise <build> dans <package> comme
ceci :
<package>
<build>
<config>--prefix=/usr --with-ssl</config>
<make>...</make>
</build>
</package>
Qui plus est, l'intérêt de pouvoir mettre dans le fichier infos les options
que le nbuildeur a décidé d'utiliser par défaut avec le script ./configure
est aussi de pouvoir en informer les utilisateurs. Prenons le scénario
suivant :
tu récupères le paquet nbuild de toto-1.0, une super application que tu veux
personnaliser pour ta machine. Quelles options vas-tu passer au
script ./configure ? D'abord tu peux faire un :
Ncooker build --help toto-1.0-nga1.nbuild
pour obtenir la liste des options utilisables avec ./configure. Mais quelles
sont celles utilisées par défaut dans le paquet ? Quelles sont celles que le
nbuildeur a choisi ? Ne le sachant pas, tu vas préciser toutes les options
pour activer et désactiver ce que tu veux ? :-) Aujourd'hui, le seul moyen de
connaître les options utilisées par défaut avec le ./configure et de
décortiquer le paquet. On ne peut pas dire que ce soit très convivial ! :-)
Par contre, si les options par défaut du ./configure sont placées dans le
fichier infos, l'utilisateur pourra faire :
Ncooker info toto-1.0-nga1.nbuild
pour les connaître. À partir de là, il pourra activer les options que le
nbuildeur n'aura pas mis par défaut, ou désactiver celles qu'il ne veut pas,
et seulement celles-là.
> > Le comportement par défaut de Ncooker serait alors de lancer «./configure
> > $NPKG_CONFIG_OPTIONS». D'un autre coté, la commande «Ncooker info
> > paquet.nbuild» montrerait, entre autres, les options utilisées par défaut
> > avec ./configure en affichant simplement la valeur de la variable
> > NPKG_CONFIG_OPTIONS.
> > Bien sûr, la commande «Ncooker build» proposerait une option pour
> > permettre à l'utilisateur de surpasser les options par défaut. Par
> > exemple :
> >
> > $ Ncooker build --config-options "--without-ssl" paquet.nbuild
> >
> > La commande lancée par Ncooker serait alors :
> >
> > ./configure $NPKG_CONFIG_OPTIONS <options passées à --config-options>
> > soit :
> > ./configure --prefix=/usr --with-ssl --without-ssl
> >
> > la dernière option annulant l'effet de la seconde.
>
> Ca on pourra le revoir plus profondemment pour un comportement global
> à Ncooker (sorte de USE ala gentoo, déjà prévu mais pas utilisé dans
> Ncooker 1.0)
Là, l'option --config-options permet de préciser des options pour ./configure
uniquement pour la compilation lancée. C'est une autre fonctionnalité que le
USE ala gentoo. C'est plus pour du cas par cas, ou lorsqu'on ne veut pas que
certaines options configurées globalement avec USE soient utilisées pour un
paquet donné.
> > - do_make() : le comportement par défaut de Ncooker est de lancer la
> > commande «make». Là aussi, on peut utiliser une variable
> > NPKG_MAKE_OPTIONS dans le fichier «infos» pour définir des paramètres à
> > utiliser avec make + une option spéciale pour la commande « Ncooker
> > build».
>
> Même remarque que pour do_config(), à part que là le comportement par
> défaut "make" tout con s'applique, contrairement à ./configure où on
> est obligé de paser au moins le --prefix
C'est vrai que généralement, le comportement par défaut « make » tout con
s'appliquera :-) . Mais si pour certains paquets des options sont
nécessaires, ce sera prévu.
> Avec mes remarques, do_config() n'est plus optionnel, sauf si on met
> globalement (dans Ncooker.conf) la fameuse option pour configure (ou
> les autres systèmes comme tu l'explique juste après), mais dans le
> fichier "infos", ça me dérange vraiment. On détourne l'utilisation
> réelle de ce fichier, et on éparpille les endroits où le mainteneur de
> Nbuild cherchera/trouvera/placera les infos.
Je ne suis pas sûr que tu es bien compris l'idée :-)
Le but n'est pas de définir pour ./configure un comportement par défaut
« global » à l'ensemble des paquets. Chaque paquet aura dans son fichier
infos des options qui lui sont propres pour le script ./configure. Et comme
je l'ai expliqué plus haut, cela a un double intérêt : contribuer à rendre le
fichier build optionnel, et donner à l'utilisateur la possibilité de
connaître ces options pour adapter à sa convenance ce qui est proposé par
défaut.
++
Gontran
