Est-il possible de définir une macro de préprocesseur dans un fichier sln et non dans un projet? (VS2008 C++)

Question

Je maintiens une grande base de code et certains fichiers vcproj sont utilisés dans différentes solutions. En raison d'une configuration et de dépendances horribles, il semble que la meilleure façon de gérer certains problèmes de construction est de #ifdef le code, mais pour cela, j'ai besoin de définir une définition de préprocesseur au niveau du fichier solution et non au niveau vcproj.

Est-ce possible?

Comment le faire?

Answer 1

2008 sln sont vraiment bêtes, ils ont seulement des listes de projets/fichiers à mettre dans l'explorateur de solution et les dépendances de projet, donc je ne pense pas que ce soit une option.

Mon instinct est de faire quelque chose avec des chemins relatifs. Par exemple, dans votre fichier stdafx.h, vous pouvez #include ".... \ project_configuration.h", puis pour construire sln a, vous allez vérifier les éléments dans un répertoire, et sln b un autre. Chacun aurait sa propre configuration_projet.h.

Je crois que vous pourriez faire quelque chose de similaire avec les fichiers vsprops, qui sont essentiellement #includes pour les fichiers vcproj, même si je les ai trouvés un peu ennuyeux à maintenir au fil du temps.

Answer 2

Sélectionnez tous les projets dans votre solution. Projet + Propriétés, C/C++, Préprocesseur, Définitions du préprocesseur. Ajouter

/DSOLUTION=$(SolutionName) 

Vous pouvez maintenant tester la solution macro valeur dans votre code source.

Answer 3

Je crois que ce que vous voulez faire est de créer une feuille de propriétés de projet avec le VS Project Manager dont tous les projets pourraient hériter. Cela vous permet de définir tous les paramètres de projet communs, y compris les macros du préprocesseur, dans un seul emplacement et de les hériter selon vos besoins.

Answer 4

Eh bien, j'ai aussi regardé

Define a preprocessor value from command line using MSBuild

et

msbuild, defining Conditional Compilation Symbols

et ceux qui pourraient travailler aussi bien, mais notre système de construction est assez fragile en ce moment et je ne suis pas une position pour tout changer.

La solution que j'ai trouvée était de cloner la configuration de construction pour le projet dans une solution et lui donner un nom différent. Puis j'ai ajouté une définition de macros/préprocesseur à cette nouvelle configuration.

Il semble fonctionner comme souhaité. Donc une solution utilise l'ancienne configuration "release" et l'autre utilise un clone "ReleaseSpecial" (pas le nom que j'ai vraiment utilisé) configuration avec différents defauts du préprocesseur.

Pas idéal, mais cela fonctionne. Ce serait bien si les propriétés étaient plus faciles à gérer ou si les fichiers SLN pouvaient passer dans les défauts du préprocesseur.

Answer 5

Une autre approch:

Modifier votre vcxproj (ou votre vcxproj.utilisateur) avec quelque chose comme ceci

<PreprocessorDefinitions Condition="'$(SolutionName)'=='NameOfYourSolution'"> 
    YOUR_DEFINITION;%(PreprocessorDefinitions) 
</PreprocessorDefinitions> 

ce n'est pas parfait car cela dépend de votre nom de fichier sln. Ce serait bien si nous utilisions une variable $ (SolutionConfiguration) à la place.

Malheureusement, je ne vois qu'une variable pour la configuration du projet: $ (Configuration).

Dans tous les cas, il fait le tour ...

Answer 6

Je trouve enfin somethings qui me convient

dans mon « C: \ Users \\ AppData \ Local \ Microsoft \ MSBuild \ v4.0 "

Je change un peu pour:

<?xml version="1.0" encoding="utf-8"?> 
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <Import Project="$(SolutionDir)\$(SolutionName).props" Condition="Exists('$(SolutionDir)\$(SolutionName).props')"/>  
</Project> 

alors maintenant, si un « mysolution.props » à côté de pond « mysolution.sln » puis-je obtenir une feuille de propriétés pour toute solution sans changer n'importe quoi dans mes projets. Cela devient une nouvelle fonctionnalité pour mon environnement visuel