vcproj, File et RelativePath

Bonjour,

je travaille sous XP avec Visual Studio 2008 en C++ non managé.

Dans un vcproj, je souhaiterais que les chemins pour les .h et .cpp soit absolus et dépendent d'une variable d'environnement LIBS. J'ai naïvement essayé de modifier le xml du .vcproj en introduisant ma variable d'environnement, mais sans succès :

Code:

---

1 2 3

<File RelativePath="$(LIBS)\include\myfile1.h"> </File>

---

Dans la fenêtre "Propriétés" du fichier "myfile1.h" il m'affiche même pas la valeur de cette variable ; il laisse le $(LIBS). A noter que cette même variable est déjà utilisée pour les répertoires d'inclusion dans les propriétés du même projet et qu'elle est correctement remplacée par sa valeur lors de la compilation. Donc la valeur de la variable est correctement récupérée par msvc. Mais visiblement, elle ne l'est pas à ce niveau là.

Évidement, les propriétés "AbsolutePath" ou "FullPath" n'existent pas.

Ces fichiers là font partis d'un dépôt CVS. Je ne veux pas les dupliquer dans mon projet. Je veux juste que mon projet pointe vers eux pour la compilation et que mes modifications bénéficient aux autres via CVS.

Est-ce que c'est possible ?

En espérant être clair ... Merci.

Flo.

Je ne comprends pas votre problème.
Est-ce dans la fenêtre propriété dans VS ?
Est-ce lors de l'édition des fichiers sources ?
Est-ce lors de la compilation du projet ?

La propagation des variables d'environnement est assez piégeuse dans les scripts MSBUILD.
Utilisez la méthode System.Environment::GetEnvironmentVariables pour bien vérifier leur valeurs lors de la compilation. http://msdn.microsoft.com/en-us/library/dd633440.aspx

Je n'ai jamais été confronté à ce type de problème car je pense qu'il y a plusieurs gros problèmes dans votre démarche, désolé.

1. La variable d'environnement est globale à l'utilisateur.
C'est très gênant pour les personnes assignées à plusieurs projets (comme les experts techniques ou les auditeurs) qui doivent jongler avec ces variables pour passer d'un projet à un autre. C'est aussi un gros problème dans le cas d'utilisation d'usine de build pour l'intégration continue où l'usine devra être configurer à chaque changement de projet et comme elle est sensé faire la compilation de tout les projets en environnement contrôlé, c'est très mal barré. :aie:
-> Utilisez des propriétés de projet SVP

2. Votre approche ne prend pas en compte les problématiques de versionning des composants externes. Chaque projet doit pouvoir choisir quel version des composants externes il utilise. Il faut pouvoir contrôler la différences de comportement induit par le changement de version d'un ou plusieurs composants externes, via les tests unitaires, donc pouvoir, pour un projet utilisateur donné, avoir le contrôle sur la version de chaque composant externe.
-> Utilisez des outils types NuGet SVP

En un mot, rationalisez et industrialisez votre processus de compilation et vous n'aurez plus ce problèmes, mais d'autres. :zoubi:
Il faut faire de votre projet utilisateur de composant une "île" qui contrôle les changements dans son environnement. Et l'utilisation systématique de chemins relatifs, qui peuvent sortir de l'arborescence du projet est une bonne solution. Vous pouvez vous sertir des outils dédiés à la gestion des packagings pour automatiser et formaliser ces dépendances.

Merci pour votre réponse. Elle est complète. En revanche, elle ne m'aide pas dans le cas présent.

Ma question est la suivante : est-il possible de modifier le vcproj (sous notepad par exemple) de manière à que l'attribut XML "RelativePath" de la balise XML "File" fasse référence à une variable d'environnement ?

Mes propres recherches sur la toile m'ont permis de constater que

Code:

---

1 2 3

<File RelativePath="$(LIBS)\include\myfile1.h"> </File>

---

ou encore

Code:

---

1 2 3

<File RelativePath="%LIBS%\include\myfile1.h"> </File>

---

ne fonctionnent pas.

Je ne parviens pas à trouver sur le site de la msdn quelque chose de suffisament précis à se sujet.

Donc quelqu'un sait-il si cela est possible et comment le faire ? C'est tout. Je n'ai pas forcément envie de rentrer dans le détail de ma démarche. Elle est ce qu'elle est avec ses propres variables d'environnement ;) elle aussi.

Merci

Flo.

Bonjour,

je n'ai jamais testé cette manip', mais elle est sûrement risquée en plus d'être peu orthodoxe. Voire impossible.
Visual a déjà toute une flopée de variables qui permettent ceci de façon fort simple. Ses propres variables d'environnement en somme.
Il convient d'utiliser les variables $(ProjectDir) et $(SolutionDir) en particulier. Afin de s'assurer que la solution soit indépendante de la machine où on la récupère.
Ces variables sont bien sur utilisables dans les include_path et lib_path.

Toute autre variable d'environnement externe à Visual est à bannir. Si tenté qu'elles soient utilisables.

Edit: à moins que le "problème" soit l'emplacement du fichier ?!
Auquel cas, je ne crois pas Visual capable de chercher un fichier comme ça. Il faut une copie du fichier que l'on incluera dans le projet, il prendra automatiquement son chemin relatif.
Et la "solution" à ce "problème" est : svn/git.

Je me rappelais plus que vcproj n'est pas un fichier MSBUILD mais un format tout pourri.

Les solutions que vous trouverez sur le Net correspondent à des fichiers MSBUILD.

Les variables d'environnements ne posent pas de problème dans des fichiers MSBUILD.

Donc, convertissez vos fichiers vcproj en fichier MSBUILD (vcxproj sius VS2010 mais je pense que c'est la même chose en VS2008).

Et comme vous le verrez sur le Net et comme je vous l'ai déjà expliqué, vous êtes en train de faire une usine à gaz pour rien.

Citation:

---

Envoyé par Flo.

Je ne parviens pas à trouver sur le site de la msdn quelque chose de suffisament précis à se sujet.

---

Tu ne dois pas bien chercher, faut dire, quelle idée d'appeler ce genre de variable : MACRO. :aie:
J'ai trouvé ça. ;) (pas sûre que ce soit la solution, mais c'est un début)