确保内部共享库版本正确 [英] Ensuring internal shared library versions are correct

问题描述

我目前的任务是尝试改进我们公司的版本控制实践，当涉及到我们的内部库。我已经阅读了语义版本2.0.0，这似乎是一个非常好的，简单和优雅的解决方案，我们当前的问题，其中我们当前的版本化实践（例如library_v01）不真正告诉我们很多关于每个库版本。

I'm currently tasked with trying to improve our companies versioning practices when it comes to our internal libraries. I've read about Semantic Versioning 2.0.0 and this seems like a really nice, simple and elegant solution to our current problem where our current versioning practices (e.g. library_v01) don't really tell us much about each library version.

理想情况下，应用程序将检查在编译时使用的库的版本，以便在部署和/或测试之前捕获任何不匹配。我们的应用程序是在Visual Studio编写的，我们很快就升级到C ++ 11编译器友好的VS2013这就是为什么我的第一个想法是使用static_asserts为了检查版本在编译时间，如：

Ideally the applications would check the version of the library being used at compile time as to catch any mismatches before a deployment and/or test. Our applications are written in Visual Studio and we're soon to upgrade to C++11 compiler friendly VS2013 which is why my first idea was to use static_asserts in order to check versions at compile time something like:

// Defined in library code and accessible by applications
struct LibraryVersion {
    static const unsigned int LIB_VERSION_MAJOR = 1;
    static const unsigned int LIB_VERSION_MINOR = 0;
    static const unsigned int LIB_VERSION_PATCH = 0;
}

// Application code
static const unsigned int EXPECTED_LIB_VERSION_MAJOR = 1;
static const unsigned int EXPECTED_LIB_VERSION_MINOR = 0;
static const unsigned int EXPECTED_LIB_VERSION_PATCH = 0;

void lib_version_check() {
    static_assert(LibraryVersion::LIB_VERSION_MAJOR == EXPECTED_LIB_VERSION_MAJOR, "Error Major");
    static_assert(LibraryVersion::LIB_VERSION_MINOR == EXPECTED_LIB_VERSION_MINOR, "Error Minor");
    static_assert(LibraryVersion::LIB_VERSION_PATCH == EXPECTED_LIB_VERSION_PATCH, "Error Patch");
}

还有一些预处理器定义可以在包含路径中使用的库支持文件，使得每个应用程序总是包括正确的库文件例如

Also it'd be nice to have some kind of pre-processor definition within a library prop file which could be used in include paths so that correct library files are always included by each application e.g.

$(LIB_DIR)="C:\Libs\"
$(LIB_VERS)="v1.0.0"
Include_Path = $(LIB_DIR)\$(LIB_VERS);

文件结构看起来像：

C:\Libs\v1.0.0\include\...
C:\Libs\v1.0.1\include\...
C:\Libs\v1.0.2\include\...
C:\Libs\v1.2.0\include\...

但是这对我来说似乎不是最优雅的解决方案，并且必须跟踪两个版本变量预处理器值和表示MAJOR，MINOR和PATCH版本的无符号整数）似乎有点多。

However this to me doesn't seem to be the most elegant solution and having to keep track of two version variables (both the pre-processor value and the unsigned integers representing MAJOR, MINOR and PATCH version) seems a bit much.

所以基本上我想询问其他人是否遇到类似的问题，如果他们对什么是优雅的解决方案有任何洞察，或者有任何陷阱使用上面的解决方案，也许我没有想过？也许有一个像上面描述的文件结构有问题和/或有一个更容易的方法？任何反馈将不胜感激。非常感谢。

So basically I'd like to ask if others have come across anything similar and if they have any insight in to what an elegant solution might be or if there are any pitfalls to using the above solution that maybe I haven't thought of? Perhaps having a file structure like the one described above is problematic and/or there is an easier way? Any feedback would be appreciated. Many thanks.

推荐答案

我们只是使用git标签作为主要，我们做你以上做的，但它是所有自动化。这不会解决编译依赖性。

We just generate a header with a template using the git tags as the major, minor and patch. We do what you have done above but it's all automated. This doesn't solve the compilation dependencies.

然而，需要什么库版本的依赖提升到我们的自定义 waf 构建系统。例如：

However, the dependency of what library versions are need is hoisted up into the package dependency of our custom waf build system. For example:

# We need boost
conf.env.BOOST_MINIMUM_VERSION = (1, 50)
conf.load('boost', tooldir=vcawaflib.dir)

# VCA project dependencies
conf.env.VCA_TEST_MINIMUM_VERSION = (0, 2, 3)
conf.project_uselib('sdk/test', 'vca_test')

构建系统与系统包管理器在Windows上，它使用我们编写的自定义python包管理器），并解析所有的依赖关系。

The build system interfaces with the systems package manager (on Windows it uses a custom python package manager we have written) and that resolves all the dependencies.

话虽如此，我们已经做了很多工作系统设置。对于你的情况，你可以允许编译器找出库依赖，但是我会使用 std :: tuple 作为正确的事情，当版本比较

That being said, it has been a lot of work to get our build system set up. For your case, you could allow the compiler to work out the library dependencies but I would use std::tuple as that does the Right Thing when it comes to version comparisons

include / my_awesome_library / version.h

namespace my_awesome_library {
  static constexpr auto version = std::make_tuple(1, 0, 0);
}  // namespace my_awesome_library

src / my_program_or_library / dependencies。 c

static_assert(my_awesome_library::version >= std::make_tuple(1, 0, 0), "\nmy_awesome_library is old");

这可以是预处理器定义为：

This could be preprocessor defined as:

#define VERSION_CHECK(version, ...) \
  static_assert(version >= std::make_tuple(__VA_ARGS__), #version " is old");

VERSION_CHECK(my_awesome_library::version, 1, 0, 0);

您可以扩展它以执行最小和最大检查等。

You could expand it to do minimum and maximum checks, etc.

微软正在做一个伟大的工作，在更高版本的Visual Studio中符合更多的标准，但你必须检查以上是否在任何MSVC编译器使用。

Microsoft are doing a great job of becoming more standards compliant in the newer versions Visual Studio but you'll have to check if the above works in whatever MSVC compiler you use.

这篇关于确保内部共享库版本正确的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！