我有一些本地的C++库(Win32,没有MFC),在Visual Studio 2005下编译,并在许多解决方案中使用。
我想根据我使用它们的特定解决方案的需求,选择将它们编译和链接为静态库或DLL。
那么,最好的方法是什么?我考虑了以下几种方法:
1. 多个项目文件
- 例如:“foo_static.vcproj”与“foo_dll.vcproj”
- 优点:易于为新库生成,不需要太多手动操作vcproj文件。
- 缺点:两个地方的设置、文件列表等很容易失去同步。
2. 单个项目文件,多个配置
- 例如:“Debug | Win32” vs “Debug DLL | Win32”,等等。
- 优点:文件列表更容易保持同步;编译选项也比较容易保持同步。
- 缺点:我同时为Win32和智能设备目标构建,所以已经有多个配置了;我不想让我的组合爆炸变得更糟糕(“FooPhone | WinMobile 6 的静态库”,“FooPhone | WinMobile 6 的动态库”,“BarPda | WinMobile 6 的静态库”等)。
- 更糟糕的缺点:VS 2005有一个坏习惯,认为如果您为平台“Foo”定义了配置,则您确实需要在解决方案中的所有其他平台上进行定义,并且无论是否有效,它都会随意地将所有配置/平台配置的排列组合插入到受影响的vcproj文件中。(已向MS提交错误报告;作为WONTFIX关闭。)
3. 单个项目文件,通过vsprops文件选择静态或动态
- 例如:将适当的vcproj片段存储在属性表文件中,然后在需要静态库时将“FooApp静态库”属性表应用于config/platform组合,在需要DLL时将“FooApp DLL”属性表应用于相应组合。
编辑: 如果有人建议,我也尝试过更“聪明”的第3种方法,其中我定义了一个 .vsprops,其中包含一个名为“ModuleConfigurationType”的 UserMacro,其值为“2”(DLL)或“4”(静态库),并将 .vcproj 中的配置更改为 ConfigurationType="$(ModuleConfigurationType)"
。 Visual Studio 会默默地且没有警告地删除该属性,并将其替换为 ConfigurationType="1"
。非常有用!
我是否错过了更好的解决方案?