Je réponds à mon premier post technique depuis mon retour :-) Le 08/07/05, Gontran<[EMAIL PROTECTED]> a écrit : > > Bonjour à tous, > > Ça faisait longtemps que je n'ai pas fait un mail de 10 pages, alors en voici > un ! :-)
ça me manquait pas ça :-) > Il reste une dernière fonction, do_static(), qui n'est pas obligatoire, et qui > sert à compiler l'application en mode «statique», c'est à dire en > incorporant directement dans le fichier binaire de l'application le code des > librairies de fonctions utilisées (en gros, hein :-) ). Elle n'est appelée > que si on invoque Ncooker avec une option spéciale, et remplace alors la > fonction do_make(). Si je ne me trompe pas, elle est utilisée pour faire le > devkit. Il faudrait savoir si elle est toujours nécessaire (Riri ?). 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(). > Toutes ces fonctions, à part do_static(), sont obligatoires dans le fichier > build, _même_ si elles ne sont pas nécessaires pour la bonne compilation de > l'application. Dans le cas où une fonction n'a pas besoin d'être utilisée, il > suffit de placer un «echo "Nothing to do."» dans son corps pour indiquer > qu'il n'y a rien à faire à cette étape. > > Voilà pour ce qui est du rappel :-) (n'hésitez pas à compléter si j'ai oublié > des choses) > > > Quelles sont les améliorations que je propose d'apporter ? > > Tout d'abord, je voudrais étoffer un peu cette liste de fonctions pour obtenir > ceci : > > - do_uncompress() > - do_patches() > - do_preconfig() > - do_config() > - do_premake() > - do_make() > - do_check() > - do_preinstall() > - do_install() > - do_postinstall() > - do_packages() > - do_help() > - do_static() (?) > > J'ai ajouté les quatre fonctions do_uncompress(), do_patches(), do_check() et > do_help(). > La première permet de réaliser soi-même la décompression des archives sources > au lieu de laisser Ncooker le faire. Ça peut s'avérer utile avec certains > paquets comme le driver Nvidia par exemple. bien > La seconde permet de séparer l'application des patches de la > «préconfiguration» avec do_preconfig(). Autrement dit, do_preconfig() > garderait son rôle actuel excepté l'application des patches, qui eux seraient > faits dans do_patches(). L'intérêt d'une telle modification n'apparaît pas > immédiatement, mais attendez la suite :-) bien aussi > 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 :-)) > La dernière enfin permet d'afficher des infos utiles pour compiler le paquet, > comme les options utilisables avec ./configure par exemple. ouaip > > Les plus attentifs auront remarqués que j'ai ajouté un «s» à la fonction > do_package() :-) car je souhaite ajouter la possibilité de générer plusieurs > NBAs à partir d'un seul NBUILD :-) C'est un autre sujet ... à creuser (mais pas 10 pages s'il te plait) > Là où ça commence à devenir plus intéressant, c'est que _toutes_ ces > fonctions, sans exception, seraient OPTIONNELLES ! C'est-à-dire que pour > certains paquets, il ne serait pas nécessaire de fournir un fichier build > pour générer un paquet NBA :-) Là je sui partant, tout en étant septique, on continue > Comment cela est-il possible ? Tout simplement en intégrant à Ncooker un > comportement par défaut, proche du fameux triplet de commandes «./configure; > make; make install» qui permet de compiler une très grande majorité > d'applications. Oui, mais ca marche pas avec Ncooker :-) > L'idée est que pour chaque étape, Ncooker regarde si le fichier build contient > une fonction associée. Si c'est le cas, il l'exécute, sinon, il utilise celle > fournit par défaut avec la commande build. Puis il passe à la suivante en > procédant de la même manière. > > Examinons à nouveau toutes les étapes en utilisant ce procédé : Bonne idée > - Décompression des archives sources : Ncooker regarde si la fonction > do_uncompress() existe. Si oui, il la lance, sinon il décompresse lui-même > les archives dans le répertoire qui va bien. oki > - Application des patches : comme précédemment, Ncooker regarde si la fonction > do_patches() existe et la lance le cas échéant. Sinon, il applique > automatiquement les patches trouvés dans le répertoire /patches du nbuild. > Plusieurs choses peuvent être mises en place ici. D'abord, on pourrait classer > les patches dans une arborescence : > > patches/ > |_ x86/ > |_ x86_64/ > > Le répertoire patches/ pourrait contenir les patches à appliquer tout le > temps, indifféremment de l'architecture matérielle du système. Le > sous-répertoire x86/ contiendrait les patches à appliquer que pour les > architectures 32bits, et x86_64/, uniquement ceux à appliquer pour les > architectures 64bits. À charge pour Ncooker de déterminer automatiquement > l'architecture matérielle. > Si cela s'avère nécessaire, on peut créer des sous-répertoires dans x86 (et > x86_64) pour les patches spécifiques à certains microprocesseurs. Par > exemple, > > patches/ > |_ x86/ > |_ pentium4 > |_ athlon-xp > > Si le microprocesseur est un athlon-xp, les patches appliqués seraient ceux > qui se trouvent dans les répertoires patches/, patches/x86/ et > patches/x86/athlon-xp/. > Là encore, à charge pour Ncooker de déterminer le type de microprocesseur. > > Si les patches sont compressées, ils sont automatiquement décompressés avant > utilisation. > Quant aux options à utiliser par défaut avec la commande «patch», j'ai > décortiqué les paquets fournis avec nasgaia 1.0.1, et le plus souvent, ce > sont les options «-Np1 -i» qui sont utilisées. Je propose donc de les > adopter par défaut. Certains paquets utilisent l'option «-p2» au lieu de > «-p1». Dans ce cas, soit on écrit la fonction do_patches() dans le fichier > build pour appliquer soi-même le patch, soit on modifie le patch pour qu'il > n'y ait qu'un seul niveau à supprimer dans le chemin du fichier («man > patch» pour ceux qui ont du mal à suivre ;-) ) oki > - do_preconfig() : le comportement par défaut de Ncooker ne fait rien. oki > - 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 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) > - do_premake() : le comportement par défaut de Ncooker de fait rien. oki > - 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 > - do_ckeck() : le comportement par défaut de Ncooker est de faire un grep sur > le fichier Makefile pour recherche une entrée «check:» ou « test:». S'il > en trouve une, il lance la commande «make» qui correspond (make check ou > make test). voir remarque au-dessus par rapport aux logiciels nécessaires > - do_preinstall() : le comportement par défaut de Ncooker ne fait rien. oki > - do_install() : le comportement par défaut de Ncooker est de lancer la > commande «make DESTDIR=$INST_ROOT install». Parfois, il faut utiliser une > autre variable que DESTDIR. Il faut voir s'il y a un moyen de la trouver > automatiquement. Sinon, il faudra écrire la fonction do_install() dans le > fichier build directement. Là ok :-) 75% des sources utilisent DESTDIR, il reste 25% à coder (personnelement, je coderai toujours le do_install(), même si le Makefile est "standard") > - do_postinstall() : Le comportement par défaut de Ncooker est de supprimer > les symboles des fichiers objets, et de placer un certains nombres de fichier > d'informations (AUTHOR, README, NEWS, CHANGELOG ...) dans le > répertoire /usr/share/doc/<nom-appli> du fakeroot s'ils existent. oki > - do_packages() : Pour ce qui est de la création des paquets NBAs, je pense > qu'il faut en parler sur un thread à part :-) Dans tous les cas, le > comportement par défaut de Ncooker est de créer un seul paquet NBA. oki > - do_help() : le comportement par défaut est d'exécuter ./configure --help > si ./configure existe, et/ou d'afficher le fichier README/INSTALL s'ils > existent. oki > Voilà pour l'idée de base :-) > La création d'un paquet nbuild serait ainsi grandement facilitée : > * dans le meilleur cas, il n'y a pas de fichier build à écrire, seules les > variables NPKG_CONFIG_OPTIONS et NPKG_MAKE_OPTIONS doivent être définies dans > le fichier «infos» (c'est Geekitus qui va être content ;-) ) > * Le cas intermédiaire est que seules certaines fonctions par défaut de > Ncooker conviennent pour compiler le paquet, mais pas d'autres. Il suffit > alors de réécrire dans le fichier build uniquement les fonctions par défaut > qui ne vont pas. > * Le pire cas est bien sûr de devoir réécrire toutes les fonctions parce le > comportement par défaut de Ncooker n'est absolument pas adapté. > 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. > Si vous avez bien assimiler cette proposition, passons à l'étape > supérieure :-) : le couple autoconf/automake n'est pas la seule manière de > compiler une application. Il existe d'autre solutions comme Scons par > exemple. Une idée pour rendre Ncooker encore plus pratique/souple serait que > la commande build ne dispose pas uniquement d'un comportement par défaut pour > autoconf/automake, mais soit livrée avec un comportement par défaut pour les > outils de construction les plus utilisés. Il détecterait automatiquement > l'outil utilisé et sélectionnerait le comportement par défaut > correspondant :-) ... > > Voilà, dites-moi ce que vous pensez de tout ça ;-) Dans l'ensemble j'aime bien, sauf le comportement par défaut avec le fichier "infos". -- Richard 'riri' GILL -- L'important dans vi, c'est maîtriser Echap et i --
