我正在尝试将项目转换为使用非递归automake。基于搜索SO,我可以看到该主题已被覆盖到一定程度。但是对于如何将递归的automake项目转换为非递归项目并没有任何问题。我已经阅读了Karel Zak's blog,当然还有autotools-mythbuster。 experiences regarding non-recursive automake有一个问题,但它没有解释如何转换项目。唯一可以解释的问题似乎是关于subdir-objects option。但我无法用这些资源转换我的项目。因此这个问题。
让我们从简单的项目设置开始:
project/
\-- configure.ac
|-- Makefile.am
\-- src/
\-- Makefile.am
|-- foo.c
|-- foo.h
\-- main.c
在configure.ac
我只需添加subdir-objects
选项:
AM_INIT_AUTOMAKE([subdir-objects])
在Makefile.am
中,我从根src
的{{1}}变量中删除了Makefiles.am
目录。然后我从`configure.ac。
SUBDIRS
宏中删除了src/Makefile
条目
Karel Zak的博客建议命名子目录AC_CONFIG_FILES
中包含的Makefile,但Makefile.am似乎也可以工作,如果为Makemodule.am
变量删除了子文件夹,并且SUBDIRS
条目已从Makefile
配置文件宏中删除。
接下来,我为根AC_CONFIG_FILES
中的程序定义了一个全局变量,并包含了src / Makefile.am
Makefile.am
在bin_PROGRAMS=
include src/Makefile.am
我改变了:
src/Makefile.am
为:
bin_PROGRAMS=foo
我还将bin_PROGRAMS+=src/foo
的所有出现更改为foo_XXX
。我在src_foo_XXX
中为所有.c和.h文件名添加了前缀src/
。
但程序没有构建,并且没有找到包含文件的错误,例如:
src_foo_SOURCES
最初我的src目录Makefile.am只包含内容变量fatal error: debug.h: No such file or directory
#include <debug.h>
,src_foo_SOURCES
,src_foo_CFLAGS
和src_foo_LDFLAGS
。我对此问题的解决方案是添加src_foo_LDADD
,如下所示:
src_foo_CPPFLAGS
但我不会&#39;我真的明白为什么这是必要的以及为什么我在使用递归automake时建好了?
关于Brett Hale in this question的回答我还有另一个问题。他写道:
您可以使用&#34; $(srcdir)/sourceA.cpp" ;,但无论如何此目录都是隐含的。您所需要的只是:
libadapter_la_SOURCES = sourceA.cpp sourceB.cpp
但是如果没有前缀路径我就无法工作,所以这对我来说似乎不对,有人可以证实我的经历吗?
更新:我也遇到了src_foo_CPPFLAGS = \
$(AM_CPPFLAGS) \
-I$(top_builddir)/src \
-DDATADIR='"$(datadir)"' \
-DMODULEDIR='"$(moduledir)"' \
-DLIBEXECDIR='"$(libexecdir)"'
子网的问题,如何进行非递归? po/
中没有Makefile.am只是一个Makevars文件。有一个post on autotools-mythbuster,表示不支持gettext的非递归制作,但该帖子是2011年的。我不确定是否有任何内容可能同时发生变化。
答案 0 :(得分:1)
我将自下而上开始:自2011年以来gettext
没有任何变化,遗憾的是,po/
目录仍应以递归方式处理。 gtk-doc
也是如此。原因是它们构建了一些 - automake
- 兼容的Makefile.in
文件,但它们并非真正基于automake
。
至于未找到的头文件,它现在失败的原因是因为您使用了错误的#include
语句格式:您应该使用#include "debug.h"
然后它将无需添加-Isrc
到命令行。预处理器将在与源文件相同的目录中查找""
个封闭的头,并在include路径中查找<>
个封闭的头; automake
默认情况下将当前目录添加到包含-I.
的包含路径,这意味着在使用递归Makefile.am
时它已满足,但现在“当前目录”不再与源文件相匹配。目录
如果您使用Karel建议的方法(Makefile.am
,或者至少某些版本的话,那么我会建议不要重复使用名称automake
,然后生成{{1}用于无法正常工作的子目录的文件,并且如果您的软件足够自包含,则考虑不使用Karel的方法,例如,如果它只有一个二进制目标。 Karel的用例是Makefile.in
,这是一个相当稀疏的项目,有几十个目标,每个目标都有自己的源文件集。
我会试着评论你注意到的Brett Hale的答案,因为我认为这完全是一种误解。