Discussion :

[LittleWhite]

Bonjour à tous,

Je me suis toujours demander comment on pouvait gérer idéalement les multiples cas des chemins menant aux ressources d'un programme.

Plus précisément, habituellement, on écrit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

loadRessource("./data/myRessource");

cela fonctionnera, jusqu'au jour où je souhaite installer mon programme sur Linux. Souvent, les programme se retrouvent dans /usr/bin et les ressources dans /usr/share, du coup, avec le code vu précédemment, les ressources ne sont pas trouvé.

Je ne doute pas que c'est un jeu avec le Makefile, mais je n'arrive pas à concevoir comment on peut faire que cela marche, aussi bien une fois que l'on est fait le make (et que les ressources soient dans les dossiers actuels) et que cela fonctionne aussi après avoir installé (make install).

Quelle est votre proposition pour faire que cela fonctionne et simplement, si possible, sans changement dans le code (et sans recompilation complète du projet ).

Merci

[Franck.H]

La meilleure solution pour ce cas est de mettre en place des compilations conditionnelles comme ça tu peux même prendre en charge tout autre OS

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
#ifdef LINUX
#   define RES_PATH "\usr\share\
#elif defined (WIN32)
#   define RES_PATH "./data/myRessource"
#endif

Enfin en gros quoi

[LittleWhite]

Oui, mais vous n'avez pas de flag pour dire comme quoi le programme est installé ou pas, si vous voulez.
La solution que nous avions actuellement, c'est de directement passé la base du chemin durant la compilation (-DMON_CHEMIN). Mais bon, si le chemin est défini, ça ne marchera pas si le programme n'est pas installé, ou des trucs dans le genre.
Je n'ai pas demandé une différence LINUX / WINDOWS, mais une différence entre les ./data et /usr/share .

[gbdivers]

Ah mon avis, le plus simple est de mettre les 2 chemins... tu recherches si les fichiers existants dans ./data/myRessource, sinon tu recherches dans \usr\share\, sinon, tu hurles
Sinon, tu as la possibilité d'utiliser un fichier de configuration avec ./data/myRessource par défaut et changer le chemin lors de l'installation (voir avoir un dialogue permettant à l'utilisateur de modifier les chemins)

[kwariz]

Bonjour,

Dans le monde linux il est courant de faire appel aux autotools (autoconf, automake, libtool, ...). En très gros ils permettent de créer un script appelé configure. Ce script accepte en options plein de paramètres, entre autre le préfixe d'installation (par exemple /usr ou /usr/local), à partir duquel il peut déduire les chemins pour installer les binaires, les bibliothèques, les données statiques, etc ..
Évidemment on peut spécifier pour chaque chemin un chemin particulier, on peut aussi créer des chemins d'installation particulier (par exemple un endroit on va installer des scripts python, etc ...).
Ce script configure a l'avantage de pouvoir être lancé de n'importe quel répertoire (pas uniquement la racine du projet). Cela permet entre autre de faire vivre en parallèle des builds release/debug/profiling avec des options différentes, d'y tester l'installation "comme si on y était".
Par exemple on peut imaginer qu'à partir d'un répértoire ~/Projets/MonProjet/Debug tu lances la commande ../configure --prefix=`pwd`/inst.
Après un make réussi, tu peux lancer un make install et tester ton programme installé.
Tu peux également préférer faire ../configure --datadir=../MesDonneesTest et ne pas faire de make install et de lancer ton exécutable directment ... Puis quand tu crées la version release tu passes les bon chemins.

Dans tous les cas de figures, cela passe par un -D donné à la commande de compilation ou un #define dans le fichier config.h (enfin presque ... mais là on entrerait trop dans les détails )

Enfin, tu peux faire un peu ce que tu veux, même si maîtriser les autotools peut parfois être fastidieux.
Toujours dans le monde linux, il est d'usage de sauver les données de l'utilisateur dans un répertoire caché à la racine de son home (par exemple tout se trouveras dans ~/.mon_application/). Il y a aussi certains standards similaires à ceux qu'on trouve sous windows : XDG. Là les chemins peuvent être dans l'environnement.

Le step suivant est de ne développer que sous linux, et de cross compiler (souvent ça marche pas trop mal). Mais là on se heurte à la création des packages pour distribuer l'application (entre les .deb les .rpm, les packages wix pour windows) ... Il faut en général adapter configure à chaque cas (les prefix peuvent changer, je ne parle pas de windows)

[gbdivers]

J'ai l'impression que vous comprenez pas la question de LittleWhite (ou c'est moi qui n'ai rien compris)
Il demande pas comment configurer les chemins lors de la compilation, mais avoir des chemins différents selon que l'application tourne en étant installé dans le /usr ou ailleurs. Le choix du chemin doit être fait lors du lancement de l'application et non lors de la compilation

[LittleWhite]

Je pensais beaucoup aux autotools, même si je n'aime pas trop les utiliser. Mais je pense que c'est la meilleure des solutions, à vrai dire. Peut être CMake en est aussi capable ?

@gbdivers : Oui, un fichier de configuration et il se trouve où ? Dans mon home, dans mon dossier courant ? et puis, il indique quel chemin ? ceux de l'application installée ou ceux du répertoire courant (chemins relatifs).

EDIT :
J'ose croire que autotool répond tout de même correctement à la question. Dans tous les cas, les chemins doivent être définis à la compilation, quitte, à comme tu l'as dit, faire plusieurs essais, puis pleurer. Il y a toujours un moment où cela doit être spécifier.

Le problème c'est que dans mon cas actuel, j'ai un makefile farfelu et que si j'installe mon logiciel et que je passe une variable avec -D je dois recompiler tout mon programme pour prendre en compte la variable

[kwariz]

Il demande pas comment configurer les chemins lors de la compilation, mais avoir des chemins différents selon que l'application tourne en étant installé dans le /usr ou ailleurs. Le choix du chemin doit être fait lors du lancement de l'application et non lors de la compilation

Quand on crée un package qui sera installé (toujours dans le monde *nix) il y a les données statiques installées lors de l'installation du package. Un utilisateur n'y a accès en général qu'en lecture jamais en écriture. Ces chemins peuvent être codés en "dur": car les chemins sont standardisés ; enfin plus ou moins, même si fedora préfèrait placer ces données dans /usr/local alors que opensuse les place dans /usr, mais quel que soit le préfixe les headers iront par défaut dans include, les binaires dans bin, les bibliothèques dans lib, etc ...
On compile avec des "#define en dur" pour chaque type de distribution.
Ensuite il y a les données utilisateurs, celles-ci sont librement placées dans le home dir (où l'utilisateur peut lire et écrire). Là aussi on peut (ou non) suivre les recommandations de certaines normes. Celles-ci peuvent être codées relativement en dur mais leurs valeurs devraient pouvoir être modifiées à l'exécution (et uniquement celles-ci), soit par un fichier de configuration, par une option sur la ligne de commande, les variables d'environnements ...

[Metalman]

Je dirais quelquechose de similaire à kwariz qui n'a pas encore été dit j'ai l'impression :
/etc

Et dedans, un dossier lié à ton projet (avec un nom donné lors de la compilation avec configure...) qui contient un fichier avec le chemin vers d'autres descripteurs de ressources si elles sont vraiment nombreuses.
Je citerais beaucoup de projets qui font plus ou moins cela : apache, squid, php, openvpn, openldap, etc....

[LittleWhite]

/etc est un dossier système pour les daemons et autres processus "importants" ou lancer en root. Donc à première vue, je ne suis pas vraiment pour.

[Franck.H]

Oui, mais vous n'avez pas de flag pour dire comme quoi le programme est installé ou pas, si vous voulez.
La solution que nous avions actuellement, c'est de directement passé la base du chemin durant la compilation (-DMON_CHEMIN). Mais bon, si le chemin est défini, ça ne marchera pas si le programme n'est pas installé, ou des trucs dans le genre.
Je n'ai pas demandé une différence LINUX / WINDOWS, mais une différence entre les ./data et /usr/share .

Ouais en fait je crois que j'ai pas bien compris le sens de la question

[Metalman]

/etc est un dossier système pour les daemons et autres processus "importants" ou lancer en root. Donc à première vue, je ne suis pas vraiment pour.

/usr/local/etc !
Bon ok sur FreeBSD le /etc est réservé au système, et l'autre aux daemons quand même...

Mais la logique reste la même : écris UN fichier dans /usr/local/share qui va dire où se trouve le reste du projet.
Et le nom de cet unique fichier sera donné lors du configure/make