Le 30/04/06, Mildred<[EMAIL PROTECTED]> a écrit :
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.
Où habites-tu donc ? au Canada ?
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.
Tiens ! C'est Houbi qui va être contente de ne pas être la seule fille ;-)
Juste une question, comment on fait si il y a un espace dans le nom du
fichier ? On met des quotes ?
Exactement
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.
En mettant des guillements lorsqu'il y a un espace, il n'y a pas de
problème. Si c'est bash qui récupère la valeur dans une variable, les
guillemets seront interprétés pour protéger le contenu. Mieux vaut
d'ailleurs mettre des guilemets simples (contenu non interprété) que
des guilemets doubles.
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é.
On peut garder le même format, et faire par exemple
NPKG_SEARCH_BINPATH=/mon/repertoire/pas/standard:$PATH
etc..
je pense que dans un premier temps en tout cas, on peut garder les noms
simples des fichiers.
On peut faire ça aussi, et voir pour passer à quelquechose de plus
compliqué si le besoin s'en faisait sentir.
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)
Ba oui, mais nous ne créons pas les programmes, nous les empaquetons :-)
Pour info, certains frameworks C++ (Juce, Ultimate++ pour ceux que je
connais, et il me semble que WxWidgets a un système de ressources
aussi) permettent d'intégrer les ressources directement au binaire,
supprimant les dépendances
--
Richard 'riri' GILL
jabber: [EMAIL PROTECTED]
http://riri.houbathecat.info
http://www.gnurou.org/Writing/SmartQuestionsFr
_______________________________________________
Nasgaia-dev mailing list
[email protected]
https://mail.gna.org/listinfo/nasgaia-dev
