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

[Grizzzly]

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

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

[AHTOXA]

Я не очень понял, для чего здесь 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) сборке возможны косяки.

[Grizzzly]

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

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

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