Le 30/04/06, Mildred <[EMAIL PROTECTED]> a écrit :
une fille !!!! mon dieu moi qui croyait etre la seule fille du projet :))) ben c'est super cool ca au moins ca montre bien que les filles peuvent etre aussi bonne et intelligente que les mecs , et toc, prenez vous ca dans les dents les mecs ;-)
Bonsoir,
Rapidement, surtout car il se fait tard et aussi parce que je n'ai pas
grand chose à dire, je trouve que tu as trouvé un bon compromis.
En tout cas, cette solution me plaît.
Merci de cette ébauche intéressante ... j'avais parlé un peu de ce que
j'imaginais mais je n'avais pas encore eu le temps, l'énergie, pour
mettre cela par écrit (ou par wiki :)
On Sat, 29 Apr 2006 14:32:33 +0200 Julien L. wrote:
> Depuis que Mildred a lancé le débat (merci à lui) et pendant que vous
> vous entre-tuiez sur l'analyse d'une situation qui n'est pas si
> pessimiste que cela selon moi, j'ai réfléchi à une implémentation de
> la gestion des dépendances. J'ai même commencé à écrire quelques
> bouts de code.
s/lui/elle/
Enfin ce n'est pas grave non plus :) C'est vrai que sur Internet on
ne sait pas forcément, surtotu que je ne corrige pas forcément.
une fille !!!! mon dieu moi qui croyait etre la seule fille du projet :))) ben c'est super cool ca au moins ca montre bien que les filles peuvent etre aussi bonne et intelligente que les mecs , et toc, prenez vous ca dans les dents les mecs ;-)
> L'idée serait d'inclure dans les paquets, zéro, un ou plusieurs
> fichiers de dépendances. Ces fichiers de dépendances seraient des
> fichiers dont chaque ligne représente une dépendance. Une ligne
> pourrait avoir l'un des trois formats suivants :
> <chemin de fichier>
> <chemin de fichier> (<nom de paquet>)
> <chemin de fichier> (<nom de paquet> <operateur> <version>)
Juste une question, comment on fait si il y a un espace dans le nom du
fichier ? On met des quotes ?
Bash c'est bien mais pour les noms de fichiers avec espaces, ça peut
être terrible. Il m'est arrivé plus d'une fois de devoir enlever les
espaces de mes noms de fichiers a cause d'un programme récalcitrant.
Même si ce n'est pas forcément conseillé, c'est toujours plus sympa de
pouvoir mettre de qu'on veut dans les noms de fichiers. Surtout si on
utilise une interface graphique (sinon, ce n'est pas intéressant)
> En relisant le débat sur la gestion des dépendances initié par
> mildred, j'ai vu que guigui proposait que les dépendances soient
> spécifiées dans le fichier "infos". C'est en effet une solution qui
> va dans l'idée initiale de Gontran : que toutes informations soient
> dans un et un seul fichier de description. Je ne sais pas trop quoi
> penser de cette idée. Elle présente des avantages et des
> inconvénients.
Personnellement, je préfère de multiples fichiers ... On peut ainsi
avoir des outils faciles, légers qui comprennent des formats de
ficheirs simples.
Je ferais même bien des configuration ou chaque clef est un nom de
fichier et chaque valeur est le contenu d'un fichier. Mais
ca devient lourd a gérer a la main quand même.
On Sat, 29 Apr 2006 15:29:23 +0200 Richard Gill wrote:
> > Voici quelques
> > exemples :
> > - si la construction du paquet dépend d'un compilateur C, le
> > Nbuildeur pourra ajouter la ligne suivante dans le fichier
> > "builddeps" : bin/cc
>
> on peut penser aussi à un mécanisme permettant de retrouver les
> binaires à partir du PATH, plutôt que ce spécifier 'bin'. La plupart
> des paquets à base des autotools permettent de spécifier un --bin-path
> - ou équivalent -, et certains logiciels ne se placent pas toujours au
> même endroit (même si les chemins relatifs bin/, lib/, etc.. sont
> majoritaires)
D'une part, quel binaire ne se situe pas dans un dossier bin ?
C'est vrai, on en a peut être quelques uns cachés dans lib mais bon ...
Ceux là ne figurent pas dans mon $PATH en tout cas. Globalement, je
pense que cela peut suffire de spécifier un chemin partiel.
Mais on peut très bien imaginer aussi avoir un format de ligne qui dise
"tel fichier se trouvant dans un dossier référancé dans telle variable"
le problème c'est que dés qu'on s'éloigne des variables standard
($PATH, $LD_LIBRARY_PATH, $C_INCLUDE_PATH et quelques autres) on peut
trouver des variables avec un format différent (des ; à la place des :
par exemple, contenant des ? devant être remplacés avec le ficheir
qu'on cherche ...) Et alors ça va devenir assez compliqué.
je pense que dans un premier temps en tout cas, on peut garder les noms
simples des fichiers.
> Hmmm, je pense qu'il faudrait éviter au maximum les chemins absolus,
> dans ce cas, share/lib/background.jpeg serait plus judicieux. cela
> utiliserait le même procédé que pour trouver les différents bin et
> lib.
Sauf que ... il y a des binaires (qu'ils soient maudits) qui
contiennent le chemin *absolu* vers des fichier ressources. Donc ce
n'est pas si illogique.
En passant, les binaires Win32 permettent d'intégrer à la compilation
les fichiers ressources ... ça a l'air bien pratique. Pourquoi n'a-t-on
pas ça avec linux ?
Et sur MacOS, ils ont des dossiers .app (comme GNUStep en fait)
contenant les fichiers ressources notament, mais pourquoi n'a-t-on pas
ça ? (ah, j'oubliais, on a GNUStep)
> Je trouve que c'est un excellent début !
de même, voir un début définitif (ou presque) pour ce qui me concerne
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]
_______________________________________________
Nasgaia-dev mailing list
[email protected]
https://mail.gna.org/listinfo/nasgaia-dev
--
Houbi "Déesse de l'enfer, mais surtout du fouet" ;-)
_______________________________________________ Nasgaia-dev mailing list [email protected] https://mail.gna.org/listinfo/nasgaia-dev
