1

Is there some way to externalize the paths of libraries that are used in the compilation process on Visual Studio 2008? Like, *.properties files?

My goal is to define "variables" referencing locations to headers files and libraries, like *.properties files are used in the Ant build system for Java.

4

5 回答 5

3

我认为您正在寻找.vsprops文件。它们与 *.properties 文件相当。

于 2010-01-25T15:23:15.557 回答
2

环境变量？

属性中允许的所有 $(xyz) 替换都是，并且您可以“自带”。

它们通常继承自父进程，因此您可以设置它们

  • 用于系统设置中的机器/用户（通常通过资源管理器继承）
  • 在运行 devenv.exe 之前设置它们的批处理文件中
  • 在像SolutionBuildEnvironment这样的插件中从项目文件中读取它们
于 2010-01-25T15:36:57.580 回答
1

我不知道 Ant 是如何工作的，但是对于您的静态库和头文件，您可以编辑该.vcproj文件。这些实际上是 XML 文件。库位于AdditionalDependencies中的VCLinkerTool工具标签中

<Tool
    Name="VCLinkerTool"
    AdditionalOptions=" /subsystem:windowsce,5.01"
    AdditionalDependencies="iphlpapi.lib commctrl.lib coredll.lib"
/>

附加头文件路径在VCCLCompilerTool工具标签中定义，在AdditionalIncludeDirectories

<Tool
    Name="VCCLCompilerTool"
    Optimization="0"
    AdditionalIncludeDirectories="dev\mydir"
    PreprocessorDefinitions="WIN32;_DEBUG;_CONSOLE"
/>

请注意，每个构建配置都有一个这样的部分。这是你想要的？

编辑：.vspropsMSalters 建议的功能更强大；您可以在其中定义其他依赖项和库，使您的项目继承这些属性。好吧，我今天学到了一些有用的东西！

于 2010-01-25T14:54:33.557 回答
1

如果您指的是影响#includes 的位置，项目属性|配置属性|C/C++/附加包含目录是票。还有项目属性|通用属性|其他参考搜索路径。

如果您的问题是我如何像在 Ant 中那样参数化 VCProj 文件中的内容，答案是在 VS2010 中 VC 项目 [/can?] 基于 MSBuild，而 VS2008 vcproj 文件是基于 XML 的专有格式 [但作为其他答案说，它们具有类似的属性能力]。

在没有更多信息的情况下，我很确定您正在做的标准方法是在第一段或第二段中添加您的搜索路径。

于 2010-01-25T14:36:49.037 回答
0

您可以使用CMake 之类的构建系统。你给 CMake 一个项目的高级描述，它会吐出必要的文件来让你的项目通过另一个工具（例如 Visual Studio 的 IDE 或 Unix 风格的 makefile）正确构建。

路径：您可以使用 CMakeList.txt 配置文件中的 CMakeINCLUDE_DIRECTORIES()和LINK_DIRECTORIES()命令来指定这些路径。CMake 具有描述环境两个方面的变量（其中许多可以自动发现，例如CMAKE_C_COMPILER运行 C 编译器的命令）以及您希望允许用户直接指定的任何选项。所有变量都存储在单独的纯文本配置文件 CMakeCache.txt 中，可以在文本编辑器中或使用特殊的 GUI 配置工具进行编辑。

CMake 具有许多其他功能，例如能够自动发现许多有用库的位置，以及使用该CONFIGURE_FILE()命令从包含 CMake 指令的“模板”文件生成自定义源/头文件。

优点：

  • 跨通用环境的高度可移植性（例如，它可以为多个版本的 MS Visual C++ 生成解决方案文件，以及为 Unix（例如 Linux）系统生成生成文件）。
  • 被多个大型多平台项目（例如 KDE）使用
  • 设置简单项目非常简单
  • 我发现依赖检查系统是坚如磐石的——例如，如果你改变编译器选项，它知道重建（不像天真的使用make例如）

缺点：

  • 丑陋的原始语法
  • 文档质量各不相同（例如，有时很难准确判断哪些属性会影响任何给定对象）
  • 涉及一些时间投资
于 2010-01-25T15:48:31.190 回答