由于 AM_INIT_AUTOMAKE 中的 subdir-objects 选项，Autotools 构建失败 [英] Autotools build fails due to subdir-objects option in AM_INIT_AUTOMAKE

问题描述

我目前正在开发一个 C++ 项目，该项目依赖于递归 automake 进行构建.我想构建一个共享库，库的src目录中的Makefile.am看起来像

I'm currently working on a C++ project which relies on recursive automake for building. I want to build a shared library and the Makefile.am in the src directory of the library looks like

# ...

# Library name
lib_LTLIBRARIES = libadapter-@MY_API_VERSION@.la

# Sources
libadapter_@MY_API_VERSION@_la_SOURCES = 
    $(top_builddir)/src/sourceA.cpp 
    $(top_builddir)/src/sourceB.cpp

# ...

从 1.14 版开始，当 configure.ac 的 AM_INIT_AUTOMAKE 中未指定 subdir-objects 选项时，automake 会发出警告.但是，添加 subdir-objects 选项似乎破坏了构建过程，make 抱怨缺少 .Plo 文件.我已经在网上搜索了遇到类似问题的人，但没有找到任何关于如何在不将项目更改为非递归项目的情况下解决问题的明智提示.非常感谢任何帮助.

Since version 1.14, automake issues a warning when the subdir-objects option is not specified in AM_INIT_AUTOMAKE in configure.ac. However, adding the subdir-objects option seems to break the build process with make complaining about missing .Plo files. I already searched the web for people experiencing similar problems but did not find any sensible hint on how to resolve the issue without changing the project to a non-recursive one. Any help is greatly appreciated.

更深入地研究这个问题，我注意到 ./configure 在库的当前源目录下创建了一个字面名为 $(top_builddir) 的目录，其中包含所有必需的.Plo 用于构建库的文件.然而，在 Makefile 中，我发现我的库源(sourceA.cpp 和 sourceB.cpp 在示例中)以 include $(top_builddir)/src/$(DEPDIR)/ 为前缀，$(top_builddir) 是定义为 相对路径(即../../../src/.deps/).现在很清楚为什么 make 找不到 .Plo 文件，因为它搜索了错误的目录.这看起来可能是错误的副本 #16375.有什么解决方法吗?

Diving more deeply into the problem, I noted that ./configure creates a directory literally named $(top_builddir) below the current source directory of the library, which contains all the required .Plo files for building the library. In the Makefile, however, I found that the .Plo equivalents of my library sources (sourceA.cpp and sourceB.cpp in the example) are prefixed by include $(top_builddir)/src/$(DEPDIR)/ and $(top_builddir) is a variable defined as a relative path (namely, ../../../src/.deps/). Now it becomes clear why make can't find the .Plo files because it searches the wrong directory. This looks like a possible duplicate of bug #16375. Any workarounds?

编辑 2:在网络上进一步挖掘发现了另外两个解决该问题的线程:#1327 和 automake-bug.一个已知的解决方法似乎是将 --disable-dependency-tracking 选项传递给 ./configure.至少对我来说是有效的.

EDIT 2: Digging further in the web revealed two more threads which address the issue: #1327 and automake-bug. A known workaround seems to be passing the --disable-dependency-tracking option to ./configure. At least for me it works.

推荐答案

来自 automake-1.14.1 NEWS 文件:

The next major Automake version (2.0) will unconditionally activate
the 'subdir-objects' option.  In order to smooth out the transition,
we now give a warning (in the category 'unsupported') whenever a
source file is present in a subdirectory but the 'subdir-object' is
not enabled.  For example, the following usage will trigger such a
warning:

        bin_PROGRAMS = sub/foo
        sub_foo_SOURCES = sub/main.c sub/bar.c

因此，如果您如上所述在对象"名称中使用子目录，那么为此做准备，您需要 subdir-objects 作为 AM_INIT_AUTOMAKE 中的选项之一.此选项在 2.0 中默认为开启".

So in preparation for this, you need subdir-objects as one of the options in AM_INIT_AUTOMAKE, if you use subdirectories in 'object' names as described above. This option will be 'on' by default in 2.0.

如果您可以为失败的目录提供 Makefile.am，它可能会提供有关为什么相关目录不匹配的线索.

If you could provide the Makefile.am for the directory that fails, it might provide a clue as to why the relative directories aren't matching up.

好的，关于这个 Makefile.am 有几件事.首先，有一些方法可以正确地对 libtool 库进行版本控制，而 @MY_API_VERSION@ 替换不是要走的路.例如，您可以在 configure.ac 中形成一个数字字符串，后跟 AC_SUBST(MY_API_VERSION).

Ok, there a couple of things about this Makefile.am. Firstly, there are ways to correctly version a libtool library, and @MY_API_VERSION@ substitutions aren't the way to go. You could form a numeric string for example, in configure.ac, followed by AC_SUBST(MY_API_VERSION).

在 Makefile.am 中:libadapter_la_LDFLAGS = -release $(MY_API_VERSION) 会将此信息放入 libadapter.la libtool 元文件.

In Makefile.am : libadapter_la_LDFLAGS = -release $(MY_API_VERSION) will put this information in the libadapter.la libtool meta-file.

对于严重版本控制，需要接口兼容性、修订、二进制兼容性等，您可以查看 版本控制.重要的系统库，尤其是 GNOME/GTK(查看它们的 configure.ac 文件！)，全力以赴.我当然不会，除非我正在考虑将某些东西释放到野外.我仍然觉得它很混乱.

For serious version control, where interface compatibility, revisions, binary compatibility, etc., are desirable, you can have a look at the libtool reference on versioning. Important system libraries, particularly GNOME/GTK (look at their configure.ac files!), go all-out on this stuff. I certainly don't, unless I'm considering releasing something into the wild. I still find it confusing.

省略@MY_API_VERSION@，您也可以坚持使用libadapter_la_SOURCES.但是，没有找到相对于任何 builddir 路径的源文件，这可能是您的 .Plo 文件问题的根源.builddir 变量描述了构建组件的位置 - 您也可以构建树外，这是一个很好的测试，看看您的 automake 设置是否健壮.一些包促进了这一点，例如，转到包的顶部，在那里创建一个名为 build 或 my_build 或任何适合的目录:

Omitting @MY_API_VERSION@, you can also stick with libadapter_la_SOURCES. However, the source files aren't found relative to any builddir path, which was perhaps the source of your .Plo file issue. The builddir variables describe where the built components are found - you can also build out-of-tree, and this is a good test to see if your automake setup is robust. Some packages promote this, e.g., go to the top of the package, make a directory there called build or my_build or whatever suits:

cd my_build;../configure <选项>;制作

包，它的源代码树和递归目录将被单独保留，所有内容都将在 my_build 目录下构建，子目录将反映您的源代码树的子目录，只有它们会充满构建的对象、库、可执行文件等.make install 也应该使用生成的 my_build/Makefile 完美运行.

The package, it's source tree and recursive directories will be left alone, everything will be built under the my_build directory, and the subdirectories will mirror those of your source tree, only they will be full of built objects, libraries, executables, etc. make install should also work perfectly using the generated my_build/Makefile.

但回到正题——那些源文件是相对于 $(srcdir) 目录的，它对应于当前(递归)Makefile.am 的目录.描述了各种 builddir 和 srcdir 变量此处.

But returning to the point - those source files are relative to the $(srcdir) directory, which corresponds to the current (recursive) Makefile.am's directory. The various builddir and srcdir variables are described here.

如果您的 src 目录位于顶级目录下，您可以使用:"$(top_srcdir)/src/sourceA.cpp" - 注意 "$(srcdir)/src/sourceA.cpp" 会错误，因为它就像指定 "$(top_srcdir)/src/src/sourceA.cpp" 在这种情况下.

If your src directory is located under the top-level directory, you could use: "$(top_srcdir)/src/sourceA.cpp" - notice that "$(srcdir)/src/sourceA.cpp" would be wrong, as it would be like specifying "$(top_srcdir)/src/src/sourceA.cpp" in this case.

你可以使用"$(srcdir)/sourceA.cpp"，但无论如何这个目录是隐式的.您只需要:

You could use "$(srcdir)/sourceA.cpp", but this directory is implicit anyway. All you need is:

libadapter_la_SOURCES = sourceA.cpp sourceB.cpp

将任何头文件放在SOURCES 列表中libadapter 使用的src 目录中也是完全可以接受的.更改标题将重建所需的内容.

It is also perfectly acceptable to put any header files in the src directory used by libadapter in the SOURCES list. A change of a header will rebuild what's required.

无论如何，我并不是想写这么多，但我知道获得有关 autotools 的明确信息是多么令人沮丧.Autotools Mythbuster 提供了出色的演练"教程，并且始终保持最新状态.

Anyway, I didn't mean to write this much, but I know how frustrating it is get clear information about the autotools. The Autotools Mythbuster provides excellent 'walk-through' tutorials, and stays very up to date.

这篇关于由于 AM_INIT_AUTOMAKE 中的 subdir-objects 选项，Autotools 构建失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！