Comment définir PreProcessorDefinitions comme une tâche propery pour la tâche msbuild

Ce qui suit est tiré à partir d'une VS2010 projet C++.

    <ClCompile>
      <WarningLevel>Level3</WarningLevel>
      <PrecompiledHeader>Use</PrecompiledHeader>
      <Optimization>MaxSpeed</Optimization>
      <FunctionLevelLinking>true</FunctionLevelLinking>
      <IntrinsicFunctions>true</IntrinsicFunctions>
      <PreprocessorDefinitions>WIN32;NDEBUG;_CONSOLE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
    </ClCompile>

Si je modifier PreprocessorDefinitions je peux mettre une définition qui est utilisée par le préprocesseur. Je peux le voir dans mon code via #ifdef etc.

Cependant, si j'utilise la suite

  <Target Name="NormalBuild" Condition=" '$(_InvalidConfigurationWarning)' != 'true' " DependsOnTargets="_DetermineManagedStateFromCL;CustomBeforeBuild;$(BuildDependsOn)" Returns="@(ManagedTargetPath)">
    <ItemGroup>
        <ManagedTargetPath Include="$(TargetPath)" Condition="'$(ManagedAssembly)' == 'true'" />
    </ItemGroup>
      <Message Text="PreprocessorDefinitions: $(PreprocessorDefinitions)" Importance="High" />
  </Target>

  <Target Name="TestBuild" Returns="@(ManagedTargetPath)">
    <MSBuild Projects="demo.vcxproj" Targets="NormalBuild" Properties="PreprocessorDefinitions=THISGETSSETBUTDOESNOTHING"/>
  </Target>

je peux aussi voir via le message que PreprocessorDefinitions contient la valeur que j'via Properties="PreprocessorDefinitions=THISGETSSETBUTDOESNOTHING" mais je ne peux pas contrôler mon build en utilisant #ifdef etc.
Si j'utilise régulièrement le programme d'installation et essayez de sortie PreprocessorDefinitions à l'aide de <Message Text="PreprocessorDefinitions: $(PreprocessorDefinitions)" le champ est en fait vide et ne contient pas les attendus <PreprocessorDefinitions>WIN32;NDEBUG;_CONSOLE;%(PreprocessorDefinitions)</PreprocessorDefinitions> bien que je peux utiliser l'une de ces touches pour contrôler mon build en utilisant #ifdef etc.

Pourquoi est-ce?
Que puis-je faire pour passer PreprocessorDefinitions für un VS2010 Projet C++ via les tâches Properties élément?

OriginalL'auteur Johannes | 2013-02-28

msbuild

7

Vous ne pouvez pas faire cela sans modifier demo.vcxproj parce que vous avez besoin de l'accès à la PreprocessorDefinitions de CLCompile, ce qui n'est pas un PropertyGroup, et ne peut donc pas être transmis via la ligne de commande MSBuild.

Vous pouvez modifier les définitions de préprocesseur dans l'interface graphique via Propriétés du Projet -> Configuration Propertis -> C/C++ -> Préprocesseur, ou de modifier directement le XML:
```
  <ClCompile>
    ....
    <PreprocessorDefinitions>$(MyMacro);%(PreprocessorDefinitions)</PreprocessorDefinitions>
  </ClCompile>
```
Dans votre projet MSBuild:
```
  <Target Name="TestBuild" Returns="@(ManagedTargetPath)">
    <MSBuild Projects="demo.vcxproj" Targets="NormalBuild" Properties="MyMacro=THISGETSSETBUTDOESNOTHING"/>
  </Target>
```
C'est équivalent à l'exécution de MSBuild.exe comme:
```
  MSBuild demo.vcxproj /p:MyMacro=THISGETSSETBUTDOESNOTHING
```
Rien de tout cela fonctionne dans mon 2017 version, et je n'ai pas de ClCompile section.
Encore du travail pour moi. Est-ce un projet C++?
Je ne travaille pas dans ce MSVC/VS monde souvent.., en plus de l'Éclipse. J'avais ajouté un nouveau dossier et vide fichier cpp, mais comme un Chemin de génération, je ne pense pas que c'était encore reconnues, et/ou le C++ 'facette n'était pas dans le "regroupement" fichier de projet. Une fois que j'ai réalisé que les erreurs ont été dans le sous-projet vcxproj les fichiers de définition de leurs propres préprocesseur des déclarations qui ont provoqué l'inondation de xkeycheck erreurs apparaissent, j'ai vu chacun de ces projets ont été ceux à modifier.. Merci bien!

OriginalL'auteur Kevin Richardson
32

Cela peut être fait sans modifier le projet initial: la première chose à faire dans Microsoft.Cpp.Targets, qui est normalement l'une des dernières choses importé dans un projet C++, est de vérifier si il y a une propriété appelée ForceImportBeforeCppTargets et, dans l'affirmative, de les importer.

Donc, supposons que vous souhaitez ajouter ADDITIONAL pour les définitions de préprocesseur vous créez un fichier "override".accessoires " comme ceci (pour l'automatisation complète utilisez le WritelinesToFile tâche de créer le fichier):
```
<?xml version="1.0" encoding="utf-8"?> 
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <ItemDefinitionGroup>
    <ClCompile>
      <PreprocessorDefinitions>%(PreprocessorDefinitions);ADDITIONAL</PreprocessorDefinitions>
    </ClCompile>
  </ItemDefinitionGroup>

</Project>
```
Et appel
```
<MSBuild Projects="demo.vcxproj" 
         Properties="ForceImportBeforeCppTargets=override.props"/>
```
ou en ligne de commande qui serait
```
msbuild demo.vcxproj /p:ForceImportBeforeCppTargets=override.props
```
Note comme richb points dans le commentaire, le ci-dessus ne fonctionne que si les remplacer.les accessoires peuvent être trouvés par msbuild est les règles de recherche. Pour s'assurer qu'il est toujours trouvé, il suffit de spécifier le chemin d'accès complet.

Merci pour cette info c'est très utile. Juste quelques corrections. Tout d'abord, le paramètre de ligne de commande est /p: non /t:. Deuxièmement, vous devez spécifier le chemin d'accès complet à remplacer.accessoires autrement msbuild ignore, c'est sans aucun avertissement.
bonne prise, édité.
Je veux juste souligner le chemin d'accès complet mention de @richb, j'ai trouvé qu'il était essentiel de faire de ce travail. Par la sortie d'un <ResourceCompile> section, il travaille avec le compilateur de ressources définitions.
Ouais en fait la dernière phrase de votre réponse est trompeuse - il ne fonctionne pas même si le fichier est situé dans le même répertoire où vcxproj est ou msbuild est appelée. Passé un certain temps à le comprendre.
désolé pour ce que je vais le changer pour juste chemin d'accès complet, qui fonctionne toujours et est mieux ractice de toute façon

OriginalL'auteur stijn

Vous devez vous connecter pour publier un commentaire.