Как создать цели для отдельных каталогов отладки и выпуска?

Question

Я ищу предложения для правильной обработки отдельных подкаталогов отладки и выпуска сборки в рекурсивной системе make-файлов, которая использует цель $ (SUBDIRS), как описано в руководстве gnumake, для применения целей создания к подкаталогам (исходного кода).

В частности, меня интересуют возможные стратегии для реализации таких целей, как «все», «чистота», «чистота» и т. Д., Которые либо предполагают одно из деревьев, либо должны работать на обоих деревьях, что вызывает проблемы.

Наши текущие make-файлы используют переменную COMPILETYPE, для которой установлено значение Debug (по умолчанию) или Release (цель 'release'), которая правильно выполняет сборки, но очищает и заставляет все работать только в дереве отладки по умолчанию. Передача переменной COMPILETYPE становится неуклюжей, потому что то, как и как это сделать, зависит от значения фактической цели.

Answer 1

Если в ваших файлах Makefiles вы дисциплинированы по поводу использования переменной $ (COMPILETYPE) для ссылки на соответствующий каталог сборки во всех ваших правилах, от правил, которые генерируют объектные файлы, до правил для clean / dist / etc, вы должны хорошо.

В одном проекте, над которым я работал, у нас была переменная $ (BUILD), для которой было установлено (эквивалентно) build- (COMPILETYPE), что немного упростило правила, поскольку все правила могли просто ссылаться на $ ( BUILD), например, clean бы rm -rf $ (BUILD).

Пока вы используете $ (MAKE) для вызова подмоделей (и используете GNU make), вы можете автоматически экспортировать переменную COMPILETYPE для всех подмоделей, не делая ничего особенного. Для получения дополнительной информации см. Соответствующий раздел руководства по сборке GNU .

Некоторые другие опции:

• Принудительная перестройка при изменении флагов компилятора путем добавления зависимости для всех объектов в метафайл, который отслеживает последний использованный набор флагов компилятора. Посмотрите, например, как Git управляет объектными файлами .
• Если вы используете autoconf / automake, вы можете легко использовать отдельный каталог сборки вне места сборки для ваших различных типов сборки. например, cd /scratch/build/$COMPILETYPE && $srcdir/configure --mode=$COMPILETYPE && make, который извлекает тип сборки из Make-файлов в конфигурацию (где вам нужно будет добавить поддержку для указания желаемых флагов сборки на основе значения --mode в вашем configure.ac)

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

Answer 2

Один из вариантов - иметь конкретные цели в подкаталогах для каждого типа сборки. Поэтому, если вы делаете «make all» на верхнем уровне, он смотрит на COMPILETYPE и при необходимости вызывает «make all-debug» или «make all-release».

В качестве альтернативы, вы можете установить переменную окружения COMPILETYPE на верхнем уровне и иметь дело с каждым подфайлом.

Реальное решение состоит не в том, чтобы делать рекурсивное создание, а в том, чтобы включать make-файлы в подкаталоги в файле верхнего уровня. Это позволит вам легко создать каталог, отличный от исходного, поэтому вы можете иметь каталоги build_debug и build_release . Он также позволяет работать параллельно make (make -j). См. Рекурсивное создание, считающееся вредным для полного объяснения.