Ожидаемая структура проекта/каталога для 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.

Исходный make-файл устанавливает переменную SOURCES, состоящую из каждого файла .c, рекурсивно найденного в src, добавляет -I./common -I./inc, создает объектные файлы и архивирует их в библиотеку. Довольно просто.

Что ж, с automake не все так просто. Я разобрался с добавлением флагов к цели сборки, например, `project_CPPFLAGS=-I./inc -I./common — это решает часть проблемы, но мне кажется, что я почему-то делаю что-то не так.

С этими (субоптимальными?) настройками я могу получить автоматическую сборку и компоновку библиотеки, что уже достаточно интересно, но настоящая причина, по которой я здесь, это make install.

Основная проблема заключается в следующем:

common содержит публичный интерфейс к библиотеке, если хотите. Он необходим для сборки исходников, но его также необходимо установить. Если я включу его из project/, то automake увидит такие пути, как common/thing.h и common/pkg/other.h, и при установке получит неверные пути в includedir. Я думал о том, чтобы он рекурсировал в этот каталог, чтобы построить проект, который имеет только установочные заголовки, но это не только плохо пахнет, но и не сработало, когда я пробовал. Заголовки библиотек нуждаются в определенной древовидной структуре -- как поддерживать древовидную структуру заголовков библиотеки, сделать их доступными для всех исходных файлов и установить их с корнем из common?

Кроме того, есть ли более элегантный способ обработки включений, чем форсирование -I? Я знаю, что мне нужно указать их как HEADERS, чтобы получить их в дистрибутивных пакетах, но на самом деле это не делает их доступными для включения, что оставляет меня немного потерянным.

Я чувствую, что automake (и, возможно, GNU в целом) ожидает какой-то структуры моего проекта, которую я просто не вижу. Если это так, скажите мне -- я готов потратить некоторое время на рефакторинг/реорганизацию проекта. Я действительно чувствую, что мне не хватает какой-то философии — текущая структура была разработана без руководства или опыта, и я никоим образом не привязан к ней.

Любая помощь приветствуется.