我不是专业从事C ++或专业使用Visual Studio进行编程的开发人员。希望这个问题不是很琐碎。
包括外部库的标准方法是在项目设置中链接它们。但是,假设我想与一些同事或朋友分享这个项目。显然,他们还将需要这些必需的库。
在CMake中,有一些模块可以检测和加载系统上可用的路径无关的库。换句话说,借助cmake查找库,它将自动将标头和其他必需内容的正确路径放入配置的解决方案 中。
CMake中的某些事情变得更加复杂,并且减慢了开发速度-例如,包括和管理资源文件。因此,我想放弃CMake以获得标准的MSBuild Visual Studio。我唯一的困扰是如何创建我的解决方案文件,使下一个要编译我的代码的人不需要将库与我放在同一位置?他们在加载解决方案时是否只需要自己配置解决方案?这里的标准做法是什么。
谢谢!
答案 0 :(得分:0)
我们对道具文件使用MSBuild支持。
props文件(例如,包含库路径的envdeppaths.x64.user.props):
<Project DefaultTargets="Build" ...>
<PropertyGroup Label="EnvDependentPaths">
<!-- base directory of boost to be used -->
<BoostDir>c:\dev\libs\boost</BoostDir>
...
这些文件包含库路径(在某些情况下,头文件和二进制文件分开), 预处理程序定义所需的内容,等等。
它们被导入类似于以下内容的项目文件中:
<Project DefaultTargets="Build" ...
<ItemGroup Label="ProjectConfigurations">
<ImportGroup Label="EnvDependentPaths">
<Import Project="$(SolutionDir)\envdeppaths.$(Platform).user.props"
Condition="exists('$(SolutionDir)\envdeppaths.$(Platform).user.props')"
Label="EnvDependentPaths" />
</ImportGroup>
...
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<ClCompile>
<WarningLevel>Level3</WarningLevel>
<AdditionalIncludeDirectories>$(BoostDir);%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
...
这种方法有一些缺点:
当然还有其他方法。 Visual Studio在配置管理器中包含用于构建属性的编辑器,而无需手动编辑。
答案 1 :(得分:0)
我在多个地方看到的是将库作为源代码管理中项目的一部分放在单独的文件夹下,例如/ extern/。
然后您在项目的include和lib dirs设置中使用相对路径来引用此外部路径
通过这种方式,您可以很好地控制项目针对哪个库版本进行编译,并且可以在源代码控制存储库中一次提交新版本的集成。
答案 2 :(得分:0)
”结果,我想放弃CMake以获得标准的MSBuild Visual Studio。我唯一的困扰是如何以下一个编译我的代码的方式创建我的解决方案文件,而无需库与我的位置完全相同吗?它们在加载解决方案时是否必须自行配置解决方案?这里的标准做法是什么。“
取决于。当可以从NuGet中获取外部库时,这很容易。只要让VS恢复第一个构建中的所有依赖关系即可。文件将落在Solution \ packages中。
如果要向解决方案中添加特定于您项目的带有源代码的DLL,则可以将它们包含在Solution \ Subdir中,并且它们的目标DLL和LIB将最终位于Solution \ Debug或\ x64 \ Debug中。
如果解决方案中有没有源的外部DLL,将它们放在\ Debug或\ x64 \ Debug中似乎是合乎逻辑的。
有时您无法重新编译或移动DLL内容。在这种情况下,请在“解决方案”中的“项目”上右键单击“项目”,选择“配置”,“链接器”,“常规”和“输入”。。在这里,您可以指定其他库子目录和其他库。
结束语:关于“配置解决方案” 备注..您来自CMake世界,习惯于手动编辑配置内容。不要在VS中打扰。将.sln内部结构留给VS,只需使用VS-2017 UI进行维护即可。