问题描述
我目前正在从事一个C ++项目，该项目依赖于递归自动制作进行构建.我想建立一个共享库，该库的src目录中的Makefile.am看起来像
# ...
# 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文件.我已经在网上搜索了遇到类似问题的人员，但是没有找到任何明智的提示来解决该问题，而无需将项目更改为非递归项目.任何帮助将不胜感激.
我更深入地探讨了这个问题，我注意到./configure在库的当前源目录下创建了一个字面名为$(top_builddir)的目录，其中包含构建库所需的所有.Plo文件.但是，在Makefile中，我发现我的库源文件中的.Plo等价物(在示例中为sourceA.cpp和sourceB.cpp)以include $(top_builddir)/src/$(DEPDIR)/为前缀，并且$(top_builddir)是定义为相对路径(即../../../src/.deps/).现在，很清楚为什么make找不到.Plo文件，因为它搜索了错误的目录.这看起来像是错误#16375 #1327 和 automake-bug .已知的解决方法似乎是将--disable-dependency-tracking选项传递给./configure.至少对我来说有效.
从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中，默认情况下此选项为"on".
如果您可以为失败的目录提供Makefile.am，则可能会提供一个线索，说明相对目录为什么不匹配.
好的，关于此Makefile.am的几件事.首先，有一些方法可以正确版本化一个libtool库，而@MY_API_VERSION@替代方法则不可行.例如，您可以在configure.ac中形成一个数字字符串，后跟 AC_SUBST(MY_API_VERSION) .
在Makefile.am中: libadapter_la_LDFLAGS = -release $(MY_API_VERSION) 会将这些信息放入libadapter.la libtool元文件中.
对于严重版本控制，需要接口兼容性，修订，二进制兼容性等，请查看版本.重要的系统库，尤其是GNOME/GTK(请看它们的configure.ac文件！)，全力以赴.我当然不会，除非我正在考虑将某些东西放到野外.我仍然感到困惑.
省略@MY_API_VERSION@，您也可以坚持使用 libadapter_la_SOURCES .但是，找不到相对于任何builddir路径的源文件，这也许是您的.Plo文件问题的来源. builddir变量描述了在哪里找到 build 组件-您也可以在树外进行构建，这是一个很好的测试，以查看您的automake设置是否可靠.某些软件包对此进行了宣传，例如，转到软件包的顶部，在该目录中创建一个名为build或my_build或其他合适名称的目录:
cd my_build; ../configure <options>; make
该软件包，其源代码树和递归目录将被保留，所有内容都将构建在my_build目录下，并且子目录将镜像您源代码树的子目录，只有它们充满了已构建的对象，库，可执行文件等.make install也应使用生成的my_build/Makefile完美运行.
但是回到这一点-这些源文件是相对于$(srcdir)目录的，该目录对应于当前(递归)Makefile.am的目录.在此处此处描述了各种builddir和srcdir变量. .
如果您的src目录位于顶级目录下，则可以使用:"$(top_srcdir)/src/sourceA.cpp"-注意"$(srcdir)/src/sourceA.cpp"将是错误，就像指定在这种情况下.
您可以使用"$(srcdir)/sourceA.cpp"，但是此目录仍然是隐式的.您只需要:
libadapter_la_SOURCES = sourceA.cpp sourceB.cpp
将所有头文件放在SOURCES列表中的libadapter使用的src目录中也是完全可以接受的.更改标头将重建所需的内容.
无论如何，我并不是要写那么多，但我知道获得有关自动工具的清晰信息会多么令人沮丧. Autotools Mythbuster 提供了出色的演练"教程，并且保持最新./p>
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
# ...
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.
EDIT: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?
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.
From the automake-1.14.1 NEWS file:
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
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.
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.
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).
In Makefile.am : libadapter_la_LDFLAGS = -release $(MY_API_VERSION) will put this information in the libadapter.la libtool meta-file.
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.
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 <options>; make
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.
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.
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.
You could use "$(srcdir)/sourceA.cpp", but this directory is implicit anyway. All you need is:
libadapter_la_SOURCES = sourceA.cpp sourceB.cpp
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.
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选项，自动工具构建失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！