我有一个支持#define的库来控制它的构建方式。但是，该库可以由需要不同版本的多个EXE项目使用。我可以让app / EXE项目在构建时设置库使用的#define，还是在解决方案中设置它？
我能想到的唯一另一个选择是在库项目上创建单独的构建配置，但这很快就会失控。这对于例如unicode / nonicode构建来说很常见，但是你最终会将每个组合的配置数量相乘。
答案 0 :(得分：5)
以下方法假定每个.EXE / app（使用此库）都有自己的Visual Studio解决方案。
你可以控制图书馆，对吗？步骤1-3将更改其项目文件，步骤4将文件添加到库源代码。
设置项目属性＆gt; C / C ++＆gt;高级＆gt;强制包含mylibrary_solution_defines.h。
编辑项目属性＆gt; C / C ++＆gt;一般＆gt;附加包含目录以将$(SolutionDir);放在目录列表的开头。
同时设置项目属性＆gt;一般＆gt;将目录和中间目录输出到与解决方案目录相关的内容。也许$(SolutionDir)$(ProjectName)\$(Configuration)？您希望确保为每个使用它的解决方案重建库;不应该共享.lib或.obj文件。
创建一个名为mylibrary_solution_defines.h的空虚拟头文件，并将其放入库源代码中，以便#include "mylibrary_solution_defines.h"永远不会失败。
在每个app / EXE解决方案中 - 假设您为使用此库的每个应用程序提供不同的解决方案，否则整个计划将失败 - 创建一个包含#defines的mylibrary_solution_defines.h文件。
你看到发生了什么吗？每个库源文件都隐式#include s "mylibrary_solution_defines.h"，并且它优先从解决方案目录中获取该文件。因此，每个解决方案的文件都可以不同。因此，如果您的解决方案ConsoleModeInterfaceProgram.sln需要使用#define TEXTONLY 1构建的库，请将该行放入与mylibrary_solution_defines.h位于同一目录中的ConsoleModeInterfaceProgram.sln。
答案 1 :(得分：0)
您需要为您的任何应用程序所需的每个库版本提供单独的构建配置。这就是构建系统的设计方式。
唯一的出路是将“库”的源代码直接添加到相应的应用程序项目中，并为每个项目设置正确的预处理器设置 - 这样，您仍然可以享受共享代码库的好处。