portabilité / chemins pour systè me de fichier

Bonjour :-)



je pars de là :
http://svn.savannah.gnu.org/viewvc/rapid?view=revision&revision=147

et j'aimerais faire le logiciel le plus portable possible


il me parait évident que forcer le séparateur à '/' ne va pas dans le sens de la portabilité


donc je vais essayer de trouver d'autres façons de faire la même chose,

le plus dur étant de ne pas perdre en fonctionnalité sous windows, parce que je n'en dispose pas pour tester,
et je n'ose pas non plus demander à Oliver Kellogg, il n'a pas le temps et il m'a déjà dit qu'il n'a pas windows non plus (donc il a probablement fait cette correction parce qu'on le lui a demandée)

alors j'espère que suffisamment de monde ici dispose de windows, et le connait suffisamment bien pour me dire sans avoir besoin de tester ce qui est fiable ou pas :-)



une chose qui me parait compliquer les choses plutôt que de les simplifier, a priori, c'est que
"On both MinGW and Cygwin, the recommended path separator is '/'"

donc on n'a pas l'obligation d'utiliser '/' à la place de '\', mais on peut le faire si on veut, et c'est même recommandé

déjà, est ce que MinGW et Cygwin sont encore d'actualité ?
j'ai entendu parler d'un sous-systeme unix intégré par microsoft, est ce que ça remplace tout, ou est ce que c'est un 3ème environnement à prendre en charge ?



alors maintenant je fais le tour de tout ce qui utilise Dir_Sep, mcc.Directory_Operations.Directory_Separator, ou GNAT.OS_Lib.Directory_Separator :


1
GtkAda

Gtkada.File_Selection.File_Selection_Dialog demande qu'on utilise GNAT.Os_Lib.Directory_Separator,
ça requiert GNAT, mais a priori ca ne pose pas de problème de portabilité ni avec windows ni avec les autres, puisque ça n'a pas été remplacé et a priori c'est bien conçu pour être portable

donc cette partie ne pose pas de problème


2
arborescence des fichiers

il y a plein de cas où on veut juste trouver le parent ou ajouter un enfant,
et on utilise le séparateur pour le faire manuellement

il me parait évident que ce qui est approprié, c'est d'utiliser Ada.Directories à la place, ainsi la plupart des problèmes de portabilité disparaissent en même temps

est ce que "." et ".." sont portables ?


à propos :
   -- get the present working directory
   -- contains Directory_Separator at end
   -- so that you can simply append a filename
   function Get_Current_Dir return String renames
     GNAT.Directory_Operations.Get_Current_Dir;

si j'ai bien compris, la concatenation proposée est une grosse erreur, il ne faut jamais faire ça et toujours utiliser Ada.Directories à la place ?


3
accès aux fichiers

je suppose qu'il n'y a aucune raison que ce qui sort de Ada.Directories ne fonctionne pas dans Ada.Text_IO, pour lire et écrire dans des fichiers

GtkAda a besoin de lire des images, aussi, mais vu le point 1 je suppose qu'il n'a pas de problème pour s'adapter à windows


4
arguments de la ligne de commande

il me semble que c'est le seul point qui peut éventuellement poser problème (si j'ai bon pour tous les autres)

je ne sais pas comment tourner ma question, parce que j'ai trop d'inconnues : par exemple,

est ce que MinGW et Cygwin sont obsolètes ?
est ce que Ada.Directories est déjà prêt, pour traiter ce qui vient de la ligne de commande, que ca soit avec le séparateur recommandé ou pas, et quel que soit le compartiment à l'intérieur de windows dans lequel ça s'exécute ?

bref, est ce que dans ce domaine là il y a des choses auxquelles je dois particulièrement faire attention, pour être bien portable, ou pas ?



sujet connexe : la portabilité avec les autres compilateurs

est il recommandé de ne pas dépendre de GNAT ?
ou est ce qu'on s'en fiche, puisque c'est du logiciel libre et que tout le monde y a accès, et c'est bête de ne pas profiter des fonctionnalités supplémentaires qu'il donne ?

là ça utilise GNAT.OS_Lib.Locate_Exec_On_Path, et je ne sais pas comment je pourrais le remplacer ...



-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/