当您设置要在 C++ 中编译的项目时，无论是 VS 还是 make，设置用于第三方库包含路径的环境变量的最佳实践是什么？您是否在变量中包含版本号？ IE。 THIRD_PARTY_LIB_3_1_1=c:\libraries\thirdparty\3.1.1
然后在您的包含路径中包含 $(THIRD_PARTY_LIB_3_1_1)\include
或者 THIRD_PARTY_LIB=c:\libraries\thirdparty\3.1.1 然后在您的包含路径中包含 $(THIRD_PARTY_LIB)\include
拥有版本号的好处是您知道应该指向哪个版本，缺点是当您更改版本时，您必须更新所有项目/制作文件。
我看到在环境变量中没有版本号的主要问题是它不是明确的，如果你有两个使用不同版本的项目，这将成为维护噩梦并且几乎不可能重现构建。
最佳答案
视情况而定。
您应该考虑构建系统如何使用该信息来更改其行为。无论您将其命名为一个或另一个，它的行为都不会有任何不同，然后它只会为您自己做更多的工作(并且可能会造成混淆)。
如果单个构建需要包含同一 THIRD_PARTY_LIBRARY 的多个版本，那么您必须加以区分。否则，当您的项目特定代码指定路径时，应该足够清楚了。
The benefit of having the version number, is that you know what version you are supposed to be pointing to, the down side is that when you change versions, you have to update all of your project/make files.
如果有人更改了路径而不是变量名，那么路径或变量名是否正确？这是一种愚蠢的想法，不是吗？如果其他人不更改变量名称，而您正试图弄清楚为什么出现问题，您也会后悔的。
The main problem I see in not having version numbers in the environment variable is that it is not explicit, and if you have two projects which use different versions, it becomes a maintenance nightmare and reproducing a build is nearly impossible.
构建文件和第 3 方库应该在源代码管理中。在进行发布构建时，您的构建系统应该记录所有这些事情。通常您希望您的构建系统能够对代码库进行完整检查以确保构建正确。作为一个副作用，它还应该知道修订号。
我的经验是，依赖环境变量是有问题的，而且它们越具体，问题就越大。很多时候你需要它们，所以我不能也不会告诉你使用它们是错误的。不过，您只能拥有一个顶级源路径环境变量。如果您的构建系统可以使用基于此的路径，那只是一个地方它会失败。如果每个库都有一个，就会增加失败点。
关于c++ - 将版本信息放入环境变量以包含第三方库的路径是否好？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7366289/