Перейти к содержанию
    

Makefile. Передача набора параметров при рекурсивном вызове

Есть основной Makefile, в котором вызываются submake. При вызове передаются два параметра: первый определяет тип проекта, а второй - релиз или дебаг. Число проектов возросло. Хочется сделать вместо тупого копирования строк $(MAKE) -f submake.mk TYPE = TYPE1 BUILD = DEBUG для всех комбинаций что-то более красивое. Можно будет тогда в "топовый" Makefile инклюдить config.mk, который будет перезаписывать переменные только для нужных сборок вместо всего набора.

 

Корректно ли использовать foreach, как в данном примере? Знаю, что не рекомендуется использовать for в мэйках. С foreach вроде бы таких проблем быть не должно. Или лучше всё-таки отказаться от него и создать цели, как здесь?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я не очень понял, для чего здесь for или foreach.

 

PROJECTS := PRJ1 PRJ2 PRJ3
OPTIONS  := DEBUG=1 OPTION1=0 OPTION2=1 OPTION10=YES

.PHONY: $(PROJECTS) 

all: $(PROJECTS)

$(PROJECTS):
    $(MAKE) -C $@ all $(OPTIONS)

 

Здесь, правда, есть потенциальная проблема в случае, если для сборки каждого проекта не организованы отдельные директории для объектных файлов (то есть, если объектные файлы при сборке разных проектов складываются в одну и ту же директорию). В этом случае при параллельной (make -j) сборке возможны косяки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо. Сборочную систему для проекта писал не я, в ней много подпроектов с десятком заинклюженных мэйкфайлов. Сейчас число комбинаций сборок растет, поэтому захотелось улучшить, но не менять структуру. Видимо, придется кое-что править. Сейчас для всех комбинаций идет вызов submakefile из цели build_all:: Поэтому сначала в ней тупо заменил десяток однотипных строк на for из shell. Это очень плохо, понимаю. Дальше решил на нативный foreach перейти, но лучше стоит переписать эти цели без него.

 

Здесь, правда, есть потенциальная проблема в случае, если для сборки каждого проекта не организованы отдельные директории для объектных файлов (то есть, если объектные файлы при сборке разных проектов складываются в одну и ту же директорию). В этом случае при параллельной (make -j) сборке возможны косяки.

Отдельные директории. С этим проблем не должно возникнуть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...