Как правильно использовать automake/autoconf с подкаталогами?

Я хочу использовать automake для проекта с большим количеством подкаталогов. Чего я хочу добиться, так это скомпилировать весь исходный код во всех подкаталогах в один исполняемый файл в Linux.

Прямо сейчас я использую subdir-objects, где мне приходится вручную указывать пути к каждому из файлов исходного кода для всей иерархии.

Я пытался использовать подход LTLIBRARIES, используя Makefile.am для каждого из подкаталогов, но по какой-то причине программа не компилируется и выдает много ошибок неопределенных ссылок.

И прямо сейчас мой файл Makefile.am выглядит так:

AUTOMAKE_OPTIONS = subdir-objects
bin_PROGRAMS = a.out
a_out_SOURCES = EntryPoint.cpp ./glad/src/glad.cpp ./ImageLoader/ImageLoader.cpp ./FileIO/FileIO.cpp ./Debug/DebugLog.cpp ./Object/Object.cpp \
./Texture/Texture.cpp ./Window/Window.cpp ./Shader/Shader.cpp
include_HEADERS = ./glad/include/glad/glad.h ./ImageLoader/stb_image.h ./FileIO/FileIO.h ./Debug/DebugLog.h ./Object/Object.h \
./Texture/Texture.h ./Window/Window.h ./Shader/Shader.h
a_out_LDADD = -lGLEW -lGL -lsfml-graphics -lsfml-window -lsfml-system -ldl -lglfw -lm

Есть лучший способ сделать это?

Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
0
405
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Прямо сейчас я использую subdir-objects, где мне нужно вручную указать пути каждого из файлов исходного кода для всей иерархии.

Вы должны указать каждый исходный файл отдельно, где-то, в любом случае.

Я пытался использовать подход LTLIBRARIES, используя Makefile.am для каждого из подкаталоги, но почему-то программа не компилируется и дает мне много неопределенных ссылочных ошибок.

Я так понимаю, вы говорите о создании служебной библиотеки для каждого подкаталога. Вы не предоставляете Makefile.am файл(ы), соответствующие этой попытке, но среди наиболее вероятных причин неопределенных ссылок, которые вы описываете, заключается в том, что вы не включили в ссылку все служебные библиотеки (перечислив их в соответствующих позициях в a_out_LDADD ).

Подход с использованием служебных библиотек имеет смысл, когда либо

  1. ваша система сборки является рекурсивной, или
  2. вы хотите построить более одной цели из одних и тех же источников.

Ни то, ни другое не верно для Makefile.am, представленного в вопросе. Его можно преобразовать в рекурсивный, но в каждом подкаталоге достаточно мало исходников, и мне это не кажется целесообразным. Результат был бы более сложным, а не менее, наряду с серьезными проблемами, связанными с верхним уровнем make отсутствием полного дерева зависимостей для работы.

Есть лучший способ сделать это?

Представленный Makefile.am похож на тот, который я бы использовал для описанного исходного макета. Изменения, которые я бы сделал, в основном стилистические:

AUTOMAKE_OPTIONS = subdir-objects

bin_PROGRAMS = a.out

a_out_SOURCES = \
  EntryPoint.cpp \
  Debug/DebugLog.cpp \
  Debug/DebugLog.h \
  FileIO/FileIO.cpp \
  FileIO/FileIO.h \
  glad/src/glad.cpp \
  glad/include/glad/glad.h \
  ImageLoader/ImageLoader.cpp \
  ImageLoader/stb_image.h \
  Object/Object.cpp \
  Object/Object.h \
  Shader/Shader.cpp \
  Shader/Shader.h \
  Texture/Texture.cpp \
  Texture/Texture.h \
  Window/Window.cpp \
  Window/Window.h
a_out_LDADD = -lGLEW -lGL -lsfml-graphics -lsfml-window -lsfml-system -ldl -lglfw -lm

Единственное семантическое изменение заключается в перемещении заголовков с include_HEADERS на a_out_SOURCES. Технически нет необходимости указывать их среди исходников программы, но это работает, и их действительно нужно где-то указывать, иначе они будут исключены из дистрибутивов. Однако они не должны быть указаны в первичном HEADERS, потому что это приведет к их установке в систему make install, и это имеет смысл только для общедоступных заголовков библиотеки.

Что менее важно, перечисление каждого файла в отдельной строке и сортировка этих строк, включая размещение заголовков рядом с соответствующими источниками, упрощает проверку и обслуживание списка источников. Отсутствие ненужного начального ./ из путей способствует тому же, облегчая чтение этих записей, по крайней мере, для меня, но различие между источниками текущего каталога и источниками подкаталога сохраняется за счет перечисления сначала всех источников текущего каталога.

Другие вопросы по теме