在sln文件中设置预处理宏而不是在项目中设置,这是否可行?(VS2008 c++)

5

我正在维护一个庞大的代码库,一些vcproj文件被用于不同的解决方案中。由于某些可怕的配置和依赖关系,处理某些构建问题的最佳方法似乎是在代码中使用#ifdef,但为了这样做,我需要在解决方案文件级别上设置预处理器定义,而不是在vcproj级别上设置。

这是否可能?

如何做到这一点?

6个回答

5
我认为你想要做的是用VS 项目管理器创建一个项目属性表,所有项目都可以继承它。这样可以在一个位置设置任何通用的项目设置,包括预处理器宏,并根据需要继承它们。

4

我终于找到了适合我的东西

在我的 "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>

现在,如果“mysolution.props”和“mysolution.sln”在一起,那么我就可以为整个解决方案获取一个属性表,而不需要更改我的项目内部的任何内容。这对于我的Visual环境来说是一个新功能。

如何在Visual Studio中检查这是否有效? :) - 我使用了类似的*.props文件,但我不知道是否使用正确。 - rezna
在想要这样做的解决方案中,向每个项目文件添加显式的“Import”元素会更安全,因为如果您在不同系统(或MSBuild工具集)之间迁移解决方案,它将继续工作。例如,如果您的计算机损坏,您重新安装操作系统,您想在多台计算机(或操作系统版本)上处理代码,或者您想与其他开发人员合作。 - SamB
(另外,您没有提到您将代码放在哪个具体文件中。) - SamB
这是一个很棒的解决方案。不过,Visual Studio 不知道它,因此智能感知可能有些问题。你将不得不依赖实际的调试器来确定哪些代码行实际上是活动的。 - Paul Knopf

4
选择解决方案中的所有项目。 选择 项目 + 属性,C / C ++,预处理器,预处理器定义。 添加
/DSOLUTION=$(SolutionName)

现在您可以在源代码中测试SOLUTION宏值。


这样做不会将预处理器宏“设置”(而不是“添加”)吗?如果您这样做,请确保项目文件的当前状态已经检入并且安全。 - sbi
@Tim:sbi说得对。如果在选择了所有项目后设置为空,那么你将需要为每个单独的项目追加它。 - Hans Passant
我只需要针对一个项目的设置,而不是解决方案中的所有项目。我只需要能够根据我所在的解决方案选择编译(或不编译)。 - Tim
好的,那就没问题了,请忽略“选择所有项目”的部分。 - Hans Passant

1

另一种方法:

使用类似以下内容编辑您的vcxproj(或vcxproj.user)

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

这并不完美,因为它取决于您的sln文件名。如果我们使用$(SolutionConfiguration)变量会更好。

不幸的是,我只看到了项目配置的变量:$(Configuration)。

无论如何,它可以解决问题...


1
我能否通过vcxproj.user取消定义预处理器宏的方式? - sergiol

1

2008年的sln非常愚蠢,它们只有项目/文件列表可以放入解决方案资源管理器和项目依赖项,因此我认为这不是一个选项。

我的直觉告诉我要使用相对路径做些什么。例如,在您的stdafx.h中,您可以#include "....\project_configuration.h",然后对于构建sln a,您会将事情检查到一个目录中,而sln b则在另一个目录中,每个目录都有其单独的project_configuration.h。

我相信你可以用vsprops文件做类似的事情,它们本质上是vcproj文件的#include,尽管我发现随着时间的推移,它们有点麻烦。


是的 - 我想 sln 文件不会有帮助。你的其他建议很有趣,但我们又回到了同样的问题 - 如何区分我们在构建项目时处于哪个 sln 中。 - Tim

0

嗯,我也看了一下

使用MSBuild从命令行定义预处理器值

msbuild,定义条件编译符号

这些也可能有效,但是我们的构建系统现在非常脆弱,我没有改变它的位置。

我想出的解决方案是在解决方案中克隆项目的构建配置并给它一个不同的名称。 然后,我向该新配置添加了宏/预处理器定义。

它似乎按预期工作。 因此,一个解决方案使用旧的“发布”配置,另一个解决方案使用克隆的“ReleaseSpecial”(我实际使用的名称不是这个)配置,具有不同的预处理器定义。

虽然不理想,但它可以工作。

如果属性更容易处理或SLN文件可以传递预处理器定义,那就太好了。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接