Я использую (GNU) Make в моем проекте. В настоящее время я помещаю один файл makefile в каталог и указываю подкаталоги с помощью SUBDIRS. Мне было предложено, что это не идеальный способ использования make, который использует один файл для создания файла (или несколько разделенных с использованием include). Я пробовал мигрировать/использовать этот макет в прошлом, но мне кажется, что это излишне сложно.
Каковы преимущества/недостатки использования рекурсивных make файлов?
Первое, что вы должны иметь в виду (просто устранить любое недоразумение), заключается в том, что мы не говорим об одном и нескольких файлах make файлов. Разделение файла makefile по одному в подкаталоге, вероятно, является хорошей идеей в любом случае.
Рекурсивные make файлы неэффективны прежде всего потому, что вы разбиваете дерево зависимостей на несколько деревьев. Это предотвращает правильное выражение зависимостей между экземплярами экземпляра. Это также приводит к тому, что дерево зависимостей многократно пересчитывается (часть), что является проблемой производительности в конце (хотя обычно это не большой).
Существует несколько трюков, которые необходимо использовать для правильного использования подхода с одним ключом, особенно если у вас большая база кода:
Во-первых, используйте GNU make (вы уже видите, я вижу). GNU make имеет ряд функций, которые упрощают работу, и вам не придется беспокоиться о совместимости.
Во-вторых, используйте значения переменной для конкретной цели. Это позволит вам иметь, например, разные значения CFLAGS для разных целей, вместо того, чтобы заставлять вас иметь один CFLAGS во всей вашей make:
main: CFLAGS=-O2
lib: CFLAGS=-O2 -g
В-третьих, убедитесь, что вы используете VPATH/vpath в полной мере, поддерживаемый GNU make.
Вы также должны убедиться, что у вас нет нескольких исходных файлов с тем же именем. Одно из ограничений VPATH заключается в том, что он не позволяет вам определять целевые VPATH для конкретных целей, поэтому имена ваших исходных файлов должны сосуществовать в одном "пространстве имен VPATH".
Статья, озаглавленная "Рекурсивная оценка считается вредной", можно найти здесь: http://miller.emu.id.au/pmiller/books/rmch/?ref=DDiyet.Com. (Или в проекте Aegis в SourceForge.)
Он исследует проблемы с рекурсивными make файлами и рекомендует подход с одним макетом.
Я использую рекурсию экстенсивно. каждый лист node будет иметь свой собственный make файл, подумайте:
$LIBS = libfoo libbar
$(LIBS):
cd [email protected] && $(MAKE)
На больших системах было бы довольно сложно не иметь эту структуру. То, что люди говорят о "рекурсивном изложении, считающемся вредным", является точной оценкой. Я думаю, что каждая ситуация немного отличается, и мы делаем некоторые компромиссы.
Запустите, не ходите, cmake.org и получите Cmake, один из лучших доступных инструментов построения.
Вы все равно будете использовать GNU make, но в этом случае CMake создаст вам файлы make.
Я не могу гарантировать 100%, но мне еще предстоит встретить случай, когда он неправильно обработал зависимости между подкаталогами правильно (т.е. проблема, которая наносит вред рекурсивному make). По крайней мере, намного проще поддерживать Cmakefiles, чем make файлы. Очень рекомендуется.
Не используйте GNU autotools - так безумие!
Makepp - ваш друг.
http://makepp.sourceforge.net/
Преимущество, которое я получил от этого в прошлом, заключается в том, что проще создавать файлы в одном подкаталоге. Вы можете сделать это с помощью зависимостей, но это немного больше, чтобы держать все цели прямо. В основном это упрощает внесение изменений и проверку одной библиотеки без необходимости справляться со всей сложностью более крупного проекта.
Чтобы добавить третий вариант, вы можете использовать GNU Autotools. В основном используется по другим причинам, но может также помочь при организации сборки с несколькими каталогами.
http://www.lrde.epita.fr/~adl/autotools.html
Следует отметить, однако, что результатом является рекурсивная версия.
Проблема с рекурсивным make - это накладные расходы времени на оценку всех разных файлов make и сравнение одного большого файла make. Часть этого процесса - это всего лишь процессы нереста, но также (IIRC) вы склонны предполагать, что другие файлы делают что-то и восстанавливают, когда вам это действительно не нужно.
Я беру на себя обязательство иметь один файл make на "Unit", что более или менее означает, что файл make для каждого фрагмента кода, который, как вы ожидаете, может использоваться на нем (например, в качестве независимой библиотеки)
OTOH мой текущий проект разбивает это по всему месту, так как я создаю файлы make во время сборки.: Б