C Automake的预期项目/目录结构？

我正在开发一个静态C库，并且一直在使用一个基本的Makefile。我们现在必须支持异地安装等等，现在是时候转向更健壮的构建标准了。我真的希望它成为自动工具——我喜欢GNU构建系统的自动一致性，我也发现它非常容易使用

也就是说，我有个问题

以下是项目结构的大致轮廓：

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

common

包含将安装在目标系统上的头文件——一个头文件直接位于common下，另一些头文件位于common/pkg中。（好吧，这不是真正的pkg，这只是一个例子。）

common

下的所有内容都是

.h

inc

包含严格与实现相关且不应公开的内部包含文件。

inc

下的所有内容都是

.h

src

为许多子模块中的每一个子模块都有一个目录，并且每个子模块可以或不可以划分为多个部分（子子模块，如果需要）。

src

下的所有内容都是

.c

原始makefile将设置一个

SOURCES

变量，该变量包含在src中递归找到的每个

.c

文件，添加

-I./common-I./inc

，构建目标文件，并将其归档到库中。很简单

嗯，对于汽车制造商来说，这似乎并不那么简单。我想出了向构建目标添加标志的办法，例如'project_CPPFLAGS=-I./inc-I./common'——这解决了部分问题，但我觉得我好像做错了什么

通过这些（次优？）设置，我可以自动生成和链接库，这已经足够令人兴奋了，但我来到这里的真正原因是

makeinstall

主要问题是：

common

包含库的公共接口（如果需要）。它是构建源代码所必需的，但也需要安装。如果我从

project/

中包含它，则automake将看到类似

common/thing.h

和

common/pkg/other.h

的路径，并在

includedir

o中获取错误路径n安装。我想让它递归到该目录中，以构建一个只包含安装头的项目，但它不仅气味难闻，而且在我尝试时不起作用。库头需要一个特定的树结构--如何维护库头树结构，使其可用于所有源文件，以及从

common

？

另外，有没有比强制使用

-I

更优雅的方法来处理include？我知道我必须将它们指定为

标题才能将它们放入分发包中，但这实际上似乎并不能使它们被包含，这让我有点不知所措

我觉得自己像汽车制造商（也许还有GNU）我希望我的项目有一些我没有看到的结构。如果是这样的话，请告诉我——我非常愿意花一些时间重构/重组项目。我真的觉得我缺少了一些哲理性的东西——目前的结构设计没有指导或经验，我不知道我喜欢它

非常感谢您的帮助。
我看不出使用
-I
有任何错误。它甚至允许在您的树和使用pkg/foo.h的第三方项目中一致使用
#include
符号

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

要在
common
中安装文件，您可以使用
SUBDIRS=common
（从顶层
Makefile.am
）

#/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

#/Makefile.am
xxxpkgdir=${includedir}/pkg
xxxpkg_头=通用/pkg/foo.h
xxxpkg2dir=${includedir}/pkg2
xxxpkg2_头=普通/pkg2/bar.h
不要使用automake。不要这样做。它所做的一切都是反向的，与最佳实践相反。Autoconf并没有那么糟糕，但没有理由使用automake。只要学习make并编写自己的makefile.R.，你能详细说明一下吗？我是一个非常有经验的程序员（并且非常熟悉make）但是，作为部署和构建管理的新手，您认为它违反了哪些最佳实践？手动编写例如安装、卸载、dist、clean、distclean等目标是否真的更好？Make是一个非常简单但功能强大的依赖项解析系统，automake将其大部分功能都丢弃，并将其用作一个愚蠢的脚本系统我见过的关于这个问题的最佳描述（不是针对汽车制造商，而是针对一般制造商的滥用）递归制造被认为是有害的：那些不了解automake的人注定会拒绝它，有时会重新发明它。很糟糕。Autotool试图封装近20年来的平台不一致、怪癖和功能缺失。丑陋的问题有时需要丑陋的解决方案。啊！我在看automake手册中的解释你怎么能在左边命名新的目录，我的直觉对我大喊大叫，但我没有把它和右边的路径剥离放在一起，直到你这么有帮助地演示。我曾经尝试过递归SUBDIR的方法，但遇到了一些问题，但我只是设置了一些类似于你上一个例子的东西，效果非常好。谢谢！
# <top>/Makefile.am
xxxpkgdir = ${includedir}/pkg
xxxpkg_HEADERS = common/pkg/foo.h
xxxpkg2dir = ${includedir}/pkg2
xxxpkg2_HEADERS = common/pkg2/bar.h