Le 04/03/06, Julien L.<[EMAIL PROTECTED]> a écrit : > Actuellement, il n'existe qu'une seule chaîne de construction : la chaîne de > compilation dite GNU. > http://svn.gna.org/viewcvs/nasgaia/trunk/ncooker/commands/build.d/buildchains/gnu.sh?rev=516&view=markup > > Elle détecte si il existe un fichier configure ou Makefile puis, si c'est le > cas, définit les étapes suivantes : > - do_config (pour faire "./configure") > - do_make (pour faire "make") > - do_install (pour faire "make install") > - do_postinstall (pour copier les fichiers de documentation et "striper" les > binaires) > - do_package (pour créer le NBA) > > Ce comportement ne me convient pas pour plusieurs raisons : > 1) le fichier Makefile n'est pas une spécificité GNU ; si je souhaite créer > un autre fichier de chaîne de construction utilisant le fichier Makefile, et > si c'est la chaîne de construction GNU qui est prioritaire, le fichier > Makefile sera tout de suite détecté par la chaîne de construction GNU. Ce > sera donc la chaîne de construction GNU qui sera utilisé par défaut et non > ma nouvelle chaîne de construction.
C'est tout simplement parce que le fichier détecté est le mauvais. Détecter un Makefile devrait activer un simple make. Pour autoconf/automake, il faut détecter ça dans l'ordre de création des fichiers lors de la conception des fichiers (dont je ne me rappelle plus exactement le role) : configure.in Makefile.am Makefile.in configure etc.. > 2) des actions ne sont pas spécifiques à la chaîne de compilation GNU > (notamment les actions des deux dernières étapes) ; si une autre chaîne de > construction serait écrite, il serait nécessaire de recopier ces deux > dernières étapes ; je pense donc que les actions des deux dernières étapes > doivent être factorisées ; Tout a fait d'accord, en fait, cela devrait être factorisé le plus possible pour reproduire au mieux le lancement 'à la main' des commandes de construction > 3) Une chaîne de construction commence par le désarchivage de la ressource ; > or, les fichiers de chaînes de construction ne peuvent définir que les > étapes allant de do_patches à do_package puisqu'elles ont besoin que la > ressource soit désarchivée afin de détecter des fichiers tels que configure > ou Makefile ; les chaînes de construction définies ne sont donc que > partielles. Exact, il doit exister des 'profils' de désarchivage tout comme pour ceux de construction. Mais cela doit déjà être fait non ? le module de désarchivage ne se base-t-il pas par défaut sur le fichier archive pour savoir que faire ? le do_unpack n'est là amha que pour les cas très spécifiques non prévus directement dans Ncooker > Parallèlement, j'ai découvert le projet bpkg : > http://swapoff.org/bpkg > > Je n'ai pas testé cet outil, étant donné que je ne possède pas l'une des > distributions requises, mais ce qui m'a intéressé sont les heuristiques > utilisées : > http://swapoff.org/bpkg#head-7ccfb720c027f5e9a1e34fad6e295540b883ebad > > Je pense qu'on pourrait s'en inspirer. D'ailleur, l'heuristique d'extraction > d'une ressource est déjà implémentée dans Ncooker. > > Voilà donc ce que je propose : un seul fichier contenant toutes les étapes > avec leur comportement par défaut (en s'inspirant éventuellement des > heuristiques définies par bpkg). On aurait donc ainsi un comportement à la > fois clair et assez complet du comportement d'un fichier build. Hmm, vu ce que tu as dis plus haut, je pensais que tu aurais dit le contraire :-) Factorisé sur la détection implique plus une factorisation des 'modèles' avec un fichier par étape. Lorsque Ncooker se génère son build maison, il va assembler les parties en fonction de ce qu'il a détecté (sauf si l'étape a été spécifiée dans le fichier build du Nbuild). Par contre, s'inspirer de la méthode heuristique de ce projet est selon moi une bonne idée, si on ne fait QUE s"en inspirer bien-sûr. > - pour l'anomalie #4755, je pense conserver l'étape do_check car c'est une > étape lancée sur demande de l'utilisateur et non systématiquement. Je trouve > qu'elle est cohérente entre les étapes do_postmake et do_preconfig. Personnelemnt je ne suis pas pour renommer do_package en do_pack. Pour moi, la symétrie avec do_unpack ne doit pas exister, car il s'agit tout simplement de deux choses différentes. do_unpack 'unpack' une archive source alors que do_package créer un package Nba, pas une archive source. do_postunpack, oui là c'est très cohérent De manière générale, je suis également pour mettre systématiquement pre et post (par exemple en renommer do_patches par do_postunpack, mais seulement si pour les packages simples (ou la plupart sont ignorés), le choix de la bonne commande reste trivial. > - pour l'anomalie #4756, je pense qu'il faut plutôt préfixer les fonctions > utilitaires par "npkg_" et les variables par "NPKG_". En effet, un fichier > build n'est pas destinée à être manipulée uniquement par Ncooker mais par > des multitudes d'outils (comme Ndeveasy par exemple). On peut même imaginer > une autre implémentation de Ncooker qui manipulerait le même format de > paquets. C'est pourquoi je pense qu'il faut préfixer par le nom du format de > paquets (npkg). C'est cohérent, je vote pour :-) -- Richard 'riri' GILL jabber: [EMAIL PROTECTED] -- L'important dans vi, c'est maîtriser Echap et i -- _______________________________________________ Nasgaia-dev mailing list [email protected] https://mail.gna.org/listinfo/nasgaia-dev
