Re: portabilité / chemins pour systè me de fichier

Bonjour :-)


Avec GNAT 4.9.3, je n'ai pas le paquetage Ada.Directories.Hierarchical_File_Names.

Ça m'embête un peu, parce que j'ai besoin de mettre au propre un minimum le traitement des chemins, pour pouvoir avancer,
mais je ne vais pas pouvoir aller au bout immédiatement, et donc je vais devoir le faire en 2 fois :-/

Je suis surpris parce que d'après la norme je croyais que ce paquetage faisait partie de Ada 2012 des le début, pas de la version corrigée par le Technical Corrigendum 1.



Le 25 janv. 2021 à 00:29, Thomas De Contes a écrit :

> 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.


(Je me demande une chose concernant la liste :
Est il approprié de vous donner des liens vers mon code via l'interface web ?
Ou de vous donner la commande svn qui vous permet de le telecharger ?)



> 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.

> 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é.



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


> 2
> Arborescence des fichiers

> Est ce que "." et ".." sont portables ?

Quelque chose m'a fait supposer que non.

- Pour ".." c'est simple : Ada.Directories.Containing_Directory

- Pour "." c'est un peu plus délicat :
A priori on peut le remplacer par Ada.Directories.Current_Directory.
  - Mais "." est un chemin relatif, alors que Ada.Directories.Current_Directory donne un chemin absolu,
  donc il peut éventuellement y avoir des cas particuliers où ça pose un problème.
  - Et aussi, est ce qu'on l'utilise uniquement seul, ou est ce qu'il peut y avoir des cas où on l'utilise avec autre chose ?
  Dans ce 2ème cas, il faudrait parcourir les possibilités, pour voir si à chaque fois on peut le remplacer par Ada.Directories.Current_Directory ou pas.


> À propos :

Dans le code de mon projet, j'ai trouvé :

>   -- 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).

> 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 ?

Si personne ne répond, je vais supposer que Ada.Directories sait traiter les chemins d'une façon un tout petit peu généraliste.
Il ne faut pas forcément qu'il le fasse trop quand même, sinon ça retire des possibilités à certaines plateformes (quand on a un caractère qui est spécial sur une plateforme mais pas sur une autre).
Mais sous windows ça parait approprié qu'il sache traiter les chemins au format UNIX, donc j'espère que c'est le cas, voilà.

> 
> 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 ?


Il y a une chose qui m'a complètement échappé quand j'ai écrit les points 3 et 4 :

Comme je vais simplifier tout ce qui peut l'être, il y a plein d'endroits où les chemins que je vais récupérer ne vont pas passer au filtre de Ada.Directories, je vais les prendre tels quels pour les envoyer à Ada.Text_IO et à GtkAda.

Donc, d'après ce que je devine, d'après mes connaissances d'aujourd'hui,
- ce qui est fourni par Gtkada.File_Selection.File_Selection_Dialog ne devrais pas poser de problème, mais
- ce qui vient de la ligne de commande, peut-être que si !

Donc j'aimerais vos avis sur ce point là, qui reste un "angle mort" pour moi (je ne sais pas si l'expression est appropriée, désolé).



Question supplémentaire (pas vraiment la suite logique) :

Ada.Directories.Set_Directory

Si j'ai bien compris, cette donnée d'environnement peut être transmise aux processus enfants, mais ne peut pas être remontée au processus parent, dû à l'architecture des OS.

Alors, quand le logiciel n'a jamais de processus enfants, est ce qu'il y a des cas où cette procédure est utile quand même, ou jamais ?

(Je vois qu'elle sert ... mais je n'en vois pas l'utilité !)



> 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 ?

Si j'ai bien compris, ce qui est recommandé c'est de ne pas en dépendre abondamment, mais c'est pas grave d'en dépendre un peu.
(Il est inutile d'avoir du travail supplémentaire le jour où on est obligé d'en utiliser un autre, si on peut faire autrement tout de suite.)

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

Donc je le garde, et ça n'est pas grave.


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

_______________________________________________
Ada-france mailing list
[email protected]
https://mail.ada-france.org/cgi-bin/mailman/listinfo/ada-france