c - Automake 的预期项目/目录结构？

Question

我正在开发一个静态 C 库，并且一直在使用一个简单的 Makefile。我们现在必须支持异地安装和诸如此类的东西，现在是转向更强大的构建标准的时候了。我真的希望它成为 autotools——我喜欢自动符合 GNU 构建系统，而且我还发现它非常容易使用。

也就是说，我有一个问题。

以下是项目结构的粗略概述:

project/
    common/
       pkg/
    inc/
    src/
       submodule1/
           some_thing/
           some_other_thing/
       submodule2/
        . . .

common 包含将安装在目标系统上的头文件——一个直接位于 common 下的头文件，以及 common/pkg 中的一些其他内容。 (好吧，这不是真正的 pkg，这只是一个例子。)common 下的所有内容都是 .h。

inc 包含严格与实现相关且不应公开的内部包含文件。 inc 下的所有内容都是 .h。

src 为许多子模块中的每一个都有一个目录，每个子模块可能会也可能不会被分成几 block (子子模块，如果你愿意的话)。 src 下的所有内容都是 .c。

原始的 makefile 会设置一个 SOURCES 变量，其中包含在 src 中递归找到的每个 .c 文件，添加 -I./common -I./inc ，构建目标文件，并将它们归档到库中。非常简单。

嗯，有了automake，好像就没那么简单了。我想出了向构建目标添加标志的方法，例如“project_CPPFLAGS=-I./inc -I./common”——这解决了部分问题，但我觉得我做错了什么，不知何故。

使用这些(次优？)设置，我可以构建 automake 并链接库，这已经足够令人兴奋了，但我来这里的真正原因是 make install。

主要问题是这样的:

common 包含库的公共(public)接口(interface)，如果你愿意的话。它需要构建源代码，但也需要安装。如果我从 project/ 中包含它，那么 automake 将看到类似 common/thing.h 和 common/pkg/other.h 的路径，并且安装时 includedir 中的路径错误。我想过让它递归到那个目录中来构建一个只有安装头文件的项目，但这不仅闻起来很糟糕，而且在我尝试时它也不起作用。库头文件需要特定的树结构——如何维护 lib 头文件树结构，使它们对所有源文件可用，并从 common 安装它们？

此外，是否有比强制 -I 更优雅的方式来处理包含？我知道我必须将它们指定为 HEADERS 才能将它们放入分发包中，但这实际上似乎并不能使它们包含在内，这让我有点迷茫。

我觉得 automake(也许一般来说是 GNU)期望我的项目有一些我没有看到的结构。 如果是这样，请告诉我 -- 我非常愿意花一些时间重构/重组项目。我确实觉得我缺少一些哲学知识——当前的结构是在没有指导或经验的情况下设计的，我对它没有任何依恋。

感谢任何帮助。

Answer 1

我没有发现使用 -I 有什么问题.它甚至允许始终如一地使用 #include <pkg/foo.h>使用 pkg/foo.h 的树和第三方项目中的符号。

AM_CPPFLAGS = -I${top_srcdir}/common -I${top_srcdir}/inc

安装 common 中的文件, 你可以利用 SUBDIRS = common (来自顶层 Makefile.am )，

# <top>/common/Makefile.am
nobase_include_HEADERS = pkg/foo.h pkg2/bar.h

或者，如果您选择执行非递归方法，例如

# <top>/Makefile.am
xxxpkgdir = ${includedir}/pkg
xxxpkg_HEADERS = common/pkg/foo.h
xxxpkg2dir = ${includedir}/pkg2
xxxpkg2_HEADERS = common/pkg2/bar.h