IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Visual C++ Discussion :

vcproj, File et RelativePath


Sujet :

Visual C++

  1. #1
    Membre averti Avatar de Flo.
    Homme Profil pro
    Inscrit en
    Mai 2002
    Messages
    379
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Mai 2002
    Messages : 379
    Points : 404
    Points
    404
    Par défaut 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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

  2. #2
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 175
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 175
    Points : 12 302
    Points
    12 302
    Par défaut
    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é.
    -> 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.
    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.

  3. #3
    Membre averti Avatar de Flo.
    Homme Profil pro
    Inscrit en
    Mai 2002
    Messages
    379
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Mai 2002
    Messages : 379
    Points : 404
    Points
    404
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    <File
           RelativePath="$(LIBS)\include\myfile1.h">
    </File>
    ou encore

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

  4. #4
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 128
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 128
    Points : 33 055
    Points
    33 055
    Billets dans le blog
    4
    Par défaut
    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.

  5. #5
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 175
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 175
    Points : 12 302
    Points
    12 302
    Par défaut
    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.

  6. #6
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2011
    Messages
    1 255
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2011
    Messages : 1 255
    Points : 2 627
    Points
    2 627
    Par défaut
    Citation Envoyé par Flo. Voir le message
    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.
    J'ai trouvé ça. (pas sûre que ce soit la solution, mais c'est un début)

Discussions similaires

  1. Réponses: 6
    Dernier message: 30/07/2003, 14h59
  2. passer FILE* en argument d une fonction
    Par Monsieur_Manu dans le forum C
    Réponses: 9
    Dernier message: 10/04/2003, 17h56
  3. [File et Directory ListBox] Soucis de filtre
    Par Mercilius dans le forum Composants VCL
    Réponses: 8
    Dernier message: 04/04/2003, 16h17
  4. A propos des 'File management Functions' de Windows
    Par znaidi dans le forum Windows
    Réponses: 3
    Dernier message: 01/04/2003, 16h01
  5. recupèrer file d'attente d'impression
    Par magic corp. dans le forum Langage
    Réponses: 2
    Dernier message: 25/09/2002, 14h12

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo