我潜入自动工具并成功完成了我的构建过程，但我最近遇到了跟踪VERSION变量的障碍。我们使用git开发为一个组，并且当前有一个系统将git commit hash的一部分加入到我们库的一部分的版本字符串中。这样，当我们编译代码时，很容易检查它是从哪个提交编译的。例如，如果我们运行mything --version，则会打印0.1.1.1f034b7。
我目前使用autotools执行此操作的解决方案涉及在存储库中使用version.sh脚本来探测提交哈希的git并输出版本字符串，如上所示。然后在configure.ac我有
AC_INIT([example],
[m4_esyscmd([./version.sh])],
[myphonyaddress@me.com],
[],
[amazingcode.com])
有了这个，我可以运行autoreconf -i，生成一个configure脚本并执行通常的./configure && make && make install。通过运行./configure，从version.cc创建名为version.cc.in的项目中的文件，将@VERSION@替换为我想要的版本字符串。这是与mything --version相关的函数所在的位置。
尽管如此，我不喜欢这样一个事实：每次我提交时，我都必须重新运行autoreconf -i，因为每次提交时，configure脚本都会过时。
我想要做的是让生成的configure脚本知道VERSION变量不是某个硬编码字符串。相反，我可以version.sh将版本字符串保存到configure脚本将读取的未跟踪文件，以确定VERSION应该是什么。
这可能没有太多多的宏观巫术吗？我想将版本设置为一次而忘记它。我也对替代解决方案持开放态度，但是不要求其他开发人员安装autotools以便做出贡献。
我知道在一般情况下，对于automake和build系统有一些强烈的意见。请不要告诉我你有多讨厌autotools。我很新，还在学习，但说实话，我觉得它根本不好。谢谢！
答案 0 :(得分：1)
之前我做过类似的事情。我在VERSION中留下了configure.ac一个静态数字，除非需要更改。正如您所发现的那样，通过提交更改修订号会很快变得乏味。
EXTRA_DIST文件（因此它与tarball捆绑在一起）。为了生成该文件，我有另一个文件作为phony target从VCS中获取修订信息（如果它检测到它使用了一个，而不是作为一个提取的源tarball）并复制自己（或者不是，如果EXTRA_DIST文件没有VCS）。根本没有宏观巫术。
因此，version是EXTRA_DIST目标，例如：
mydef_version=`cat version`
AC_DEFINE_UNQUOTED([VERSION_GIT],["$mydef_version"])
configure.ac中的会为您的C ++翻译单元设置一个定义：
const char version_info[] = VERSION "." VERSION_GIT;
EXTRA_DIST文件也可以是一个自包含的翻译单元，只有版本信息。
我在我的CI服务器上使用rpmbuild，需要使用tarball来构建而不是签出的repo，所以基本上构建的第一阶段基本上是autoreconf...; ./configure...; make dist;，第二阶段是{ {1}}。