Я занимаюсь разработкой статической библиотеки C и использую простой Makefile.Теперь нам приходится поддерживать установки вне офиса и все такое, и пришло время перейти к более надежному стандарту сборки.Я действительно хочу, чтобы это были автоинструменты - мне нравится автоматическое соответствие GNU Build System, и я также обнаружил, что с ним довольно легко работать.
Тем не менее, у меня проблема.
Вот примерная схема структуры проекта:
project/
common/
pkg/
inc/
src/
submodule1/
some_thing/
some_other_thing/
submodule2/
. . .
common содержит файлы заголовков, которые будут установлены в целевой системе - один заголовок под общей и некоторые другие общие элементы/ упак.(Ну, на самом деле это не pkg, это всего лишь пример.) Все в common равно .h.
inc содержит внутренние включаемые файлы, которые строго относятся к реализации и не должны быть доступны.Все в inc равно .h.
src имеет каталог для каждого из нескольких подмодулей, и каждый из подмодулей может или не может быть разделен на части (подмодули, если хотите),Все в src равно .c.
Исходный файл makefile установит переменную SOURCES, состоящую из каждого .c файла, найденного рекурсивно в src, добавит -I./common -I./inc, создаст объектные файлы и архивих в библиотеку.Довольно просто.
Ну, с automake, это не так просто.Я разобрался с добавлением флагов к цели сборки, например `project_CPPFLAGS = -I. / Inc -I./common" - это решает часть проблемы, но я чувствую, что что-то делаю не так.
С этими (неоптимальными?) Настройками я могу заставить сборку и сборку automake библиотекой, что уже достаточно увлекательно, но настоящая причина, по которой я здесь, - make install.
Основнаяпроблема заключается в следующем:
common содержит общедоступный интерфейс к библиотеке, если хотите. Он необходим для создания исходных текстов, но также должен быть установлен. Если я включаю его из project/,затем automake увидит пути, такие как common/thing.h и common/pkg/other.h, и при установке получит неправильные пути в includedir. Я думал о том, чтобы он возвращался в этот каталог для создания проекта, который имеет только заголовки установки, но который не только пахнетплохо, это не сработало, когда я попробовал. Заголовки библиотеки нуждаются в определенной древовидной структуре - как мне поддерживать древовидную структуру заголовка lib, сделать их доступными для всех кислыхФайлы ce и установите их с корнем из common?
Кроме того, есть ли более элегантный способ обработки включений, чем форсирование -I?Я знаю, что нужно указать их как HEADERS, чтобы получить их в дистрибутивных пакетах, но на самом деле это, кажется, не делает их доступными для включения, поэтому я немного растерялся.
Я чувствую себя automake (и, возможно, GNU в целом) ожидает некоторой структуры для моего проекта, которую я просто не вижу. Если это так, пожалуйста, скажите мне - Я совершенно готов потратить некоторое время на рефакторинг / реорганизацию проекта.Я действительно чувствую, что мне не хватает какой-то философской мысли - нынешняя структура была разработана без руководства или опыта, и я никоим образом не привязан к ней.
Любая помощь приветствуется.