你能做一个 VC++解决方案在加载的项目上设置预处理器#defines？
我有一个支持 #define 的库来控制它的构建方式。然而，该库可以被需要不同版本的多个 EXE 项目使用。我可以让 app/EXE 项目设置 #define 在构建时由库使用，或者在解决方案中设置吗？
我能想到的唯一其他选择是在库项目上创建一个单独的构建配置，但这很快就会失去控制。这对于例如 unicode/非 unicode 构建来说很常见，但最终您会增加每个组合的配置数量。
I have a library which supports a #define to control how it's built. However the library can be used by multiple EXE projects which want different versions. Can I make the app/EXE project set the #define to be used by the library when built, or set it in the solution?
The only other option I can think of is creating a separate build-configuration on the library project but that would quickly get out of control. That's common for e.g unicode/non-unicode builds but then you'd end up multiplying the number of configurations for every combination.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
以下方法假设每个 .EXE/app（使用此库）都有自己的 Visual Studio 解决方案。
你确实拥有图书馆的控制权，对吗？步骤 1-3 将对其项目文件进行更改，步骤 4 将文件添加到库源代码中。
设置项目属性> C/C++>高级>强制包含到
mylibrary_solution_defines.h。编辑项目属性> C/C++>一般>其他包含目录将
$(SolutionDir);放在目录列表的开头。设置两个项目属性>一般>输出目录和中间目录相对于解决方案目录。也许
$(SolutionDir)$(ProjectName)\$(Configuration)？您希望确保为每个使用它的解决方案重建该库；不应共享 .lib 或 .obj 文件。创建一个名为
mylibrary_solution_defines.h的空虚拟头文件，并将其放入库源代码中，以便#include "mylibrary_solution_defines.h"永远不会失败。< /p>在每个应用程序/EXE 解决方案中 - 假设您对使用此库的每个应用程序都有不同的解决方案，否则整个计划将失败 - 创建一个
mylibrary_solution_defines.h文件，其中包含 #defines你看到发生了什么事吗？每个库源文件都隐式地
#includes“mylibrary_solution_defines.h”，并且它优先从解决方案目录获取该文件。因此该文件对于每个解决方案都可能不同。因此，如果您的解决方案ConsoleModeInterfaceProgram.sln需要使用#define TEXTONLY 1构建的库，请将该行放入同一目录中的mylibrary_solution_defines.h中目录为ConsoleModeInterfaceProgram.sln。The following approach assumes that every .EXE/app (which uses this library) has its own Visual Studio Solution.
You do have control over the library, right? Steps 1-3 will make changes to its project file, and step 4 adds a file to the library source code.
Set Project Properties > C/C++ > Advanced > Force Includes to
mylibrary_solution_defines.h.Edit Project Properties > C/C++ > General > Additional Include Directories to put
$(SolutionDir);at the beginning of the list of directories.Set both Project Properties > General > Output Directory and Intermediate Directory to something relative to the solution directory. Perhaps
$(SolutionDir)$(ProjectName)\$(Configuration)? You want to make sure the library gets rebuilt for every solution that uses it; there shouldn't be any sharing of .lib or .obj files.Create an empty, dummy header file called
mylibrary_solution_defines.hand put it in your library source code so a#include "mylibrary_solution_defines.h"will never fail.In every app/EXE solution -- assuming you have different solutions for each app that uses this library, otherwise this whole plan will fail -- create a
mylibrary_solution_defines.hfile with your #defines in it.Do you see what's happening? Every library source file implicitly
#includes"mylibrary_solution_defines.h", and it preferentially gets that file from the solution directory. So that file can be different for every solution. So if your solutionConsoleModeInterfaceProgram.slnneeds the library built with#define TEXTONLY 1, put that line into themylibrary_solution_defines.hthat's in the same directory asConsoleModeInterfaceProgram.sln.您需要为任何应用程序所需的每个库版本单独的构建配置。这就是构建系统的设计方式。
唯一的出路是将“库”的源代码直接添加到相应的应用程序项目中，并为每个项目设置正确的预处理器设置 - 这样，您仍然可以享受共享代码库的好处。
You'll need separate build configurations for each library version that any of your applications requires. That's how the build system is designed.
The only way out would be to add the source code for the 'library' directly to the respective application projects and set the correct preprocessor settings per-project - this way, you still have the benefit of a shared codebase.