我正在维护一个庞大的代码库,一些vcproj文件被用于不同的解决方案中。由于某些可怕的配置和依赖关系,处理某些构建问题的最佳方法似乎是在代码中使用#ifdef,但为了这样做,我需要在解决方案文件级别上设置预处理器定义,而不是在vcproj级别上设置。
这是否可能?
如何做到这一点?
我正在维护一个庞大的代码库,一些vcproj文件被用于不同的解决方案中。由于某些可怕的配置和依赖关系,处理某些构建问题的最佳方法似乎是在代码中使用#ifdef,但为了这样做,我需要在解决方案文件级别上设置预处理器定义,而不是在vcproj级别上设置。
这是否可能?
如何做到这一点?
我终于找到了适合我的东西
在我的 "C:\Users\\AppData\Local\Microsoft\MSBuild\v4.0" 目录下
我稍微更改了一下:
<?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>
/DSOLUTION=$(SolutionName)
现在您可以在源代码中测试SOLUTION宏值。
另一种方法:
使用类似以下内容编辑您的vcxproj(或vcxproj.user)
<PreprocessorDefinitions Condition="'$(SolutionName)'=='NameOfYourSolution'">
YOUR_DEFINITION;%(PreprocessorDefinitions)
</PreprocessorDefinitions>
这并不完美,因为它取决于您的sln文件名。如果我们使用$(SolutionConfiguration)变量会更好。
不幸的是,我只看到了项目配置的变量:$(Configuration)。
无论如何,它可以解决问题...
2008年的sln非常愚蠢,它们只有项目/文件列表可以放入解决方案资源管理器和项目依赖项,因此我认为这不是一个选项。
我的直觉告诉我要使用相对路径做些什么。例如,在您的stdafx.h中,您可以#include "....\project_configuration.h",然后对于构建sln a,您会将事情检查到一个目录中,而sln b则在另一个目录中,每个目录都有其单独的project_configuration.h。
我相信你可以用vsprops文件做类似的事情,它们本质上是vcproj文件的#include,尽管我发现随着时间的推移,它们有点麻烦。
嗯,我也看了一下
和
这些也可能有效,但是我们的构建系统现在非常脆弱,我没有改变它的位置。
我想出的解决方案是在解决方案中克隆项目的构建配置并给它一个不同的名称。 然后,我向该新配置添加了宏/预处理器定义。
它似乎按预期工作。 因此,一个解决方案使用旧的“发布”配置,另一个解决方案使用克隆的“ReleaseSpecial”(我实际使用的名称不是这个)配置,具有不同的预处理器定义。
虽然不理想,但它可以工作。
如果属性更容易处理或SLN文件可以传递预处理器定义,那就太好了。