Le Lundi 11 Juillet 2005 19:09, Julien L. a écrit : > Salut tout le monde, > Salut Gontran, > > Un fichier XML à la place de trois fichiers texte "basique" ? Pourquoi pas. > Cela dit, pour le développeur, ce n'est pas vraiment facile d'écrire du > XML. Enfin bon, avec un bon éditeur, cela peut le faire...
Pour faciliter les choses, j'ai pensé à une commande « wizard » pour Ncooker. L'idée est que si on lance simplement « Ncooker wizard », une série de questions est posée à l'utilisateur pour créer un répertoire avec les fichiers infos et build, puis générer un nbuild automatiquement. Si on lance « Ncooker wizard --files toto », ça créerait un répertoire toto avec un modèle de fichiers infos et build, que l'utilisateur devrait compléter à la main ... > Un jour, il me semble avoir lu que les toutes premières versions de Ncooker > utilisaient du XML et que le format XML fut finalement abandonné au profit > de fichiers texte "basiques". Est-ce que les anciens savent la raison du > pourquoi ? Perso, je n'en ai pas entendu parlé. Un « plus ancien » que moi le sait ? :-) > Je me pose également une autre question. Dans la version en développement > de Ncooker, le traitement de création d'un Nbuild ajoute des informations > dans les fichiers infos et changelog. Est-ce que ce comportement serait > conservé avec un tel fichier XML ? Oui > J'imagine que c'est assez simple de rajouter des lignes dans les fichiers > infos et changelog. Est-ce qu'il est aussi simple de rajouter des > informations dans un fichier XML ? Le toolkit XmlStarLet permet d'éditer un fichier xml en ligne de commande, un peu comme sed. il est possible d'ajouter des balises ou des attributs, de modifier le contenu des balises/attributs existants, de déplacer des noeuds, etc. Donc oui, c'est parfaitement faisable. > Sinon, je suis favorable à rendre les fonction do_* optionnelles mais je > préférerais que leur comportement par défaut ne soit pas orienté vers une > chaîne de compilation en particulier (./configure && make && make install > en l'occurence). Je ne vois pas pourquoi on favoriserait une chaîne de > compilation en particulier sous prétexte qu'elle est majoritairement > utilisée à l'heure actuelle. Avec le temps, cette chaîne de compilation > peut devenir obsolète. Oui, c'est pour cela que j'ai proposé que les comportements par défaut soit codés sous forme de sous-module de la commande build. Chaque sous-module correspondrait à une chaine de compilation donnée. Ncooker devrait alors détecter automatiquement quel sous-module utiliser en fonction des fichiers trouvés dans les archives sources. > Je suis plutôt favorable que les fonctions de compilation n'aient aucun > comportement par défaut. Je pense que le développeur de Nbuild sera ainsi > contraint de maîtriser la construction de son Nbuild, ie, de se poser les > questions sur la bonne commande ./configure, la bonne commande make, ... > qu'il doit utiliser pour construire le paquet. Ton point de vue se défend :-) La raison pour laquelle j'ai proposé des comportements par défaut pour toutes les fonctions est aussi de permettre à ceux qui s'y connaissent un peu moins de faire leur premier pas dans la réalisation de NBUILDs. Ça leur permettrait d'obtenir un premier résultat rapidement et de leur donner envie daller plus loin dans la personnalisation de leurs paquets. Reste à voir s'ils le feraient :-) ... > Pour ce qui est des fonctions qui peuvent avoir un comportement par défaut > pour tous les paquets possibles, il ne faut pas se priver. Je pense > notamment à do_package. On y met toujours la même chose, non ? Pas toujours, mais très souvent oui, c'est la même chose. ++ Gontran
