Могут ли цели GNU make зависеть от завершения целей из других make-файлов?

#makefile #gnu-make

Вопрос:

У меня есть несколько каталогов, представляющих части проекта, каждая со своим собственным Makefile.
Я хочу создать главный Makefile с целями для каждого из этих подразделов, каждая цель удовлетворяет следующим:

зависят от определенной цели из Makefile этого подпроекта.
Это сложная часть.
скопируйте некоторую результирующую сборку библиотеки / исполняемого файла с помощью подпроекта в центральный каталог (что-то вроде «make install»).
Этого я уже могу достичь с помощью простых команд.

Я смог найти информацию только о include директиве GNU make, но это мне не очень помогло, поскольку, похоже, она не инкапсулирует правила (и выполнение) включенного make-файла в его собственный каталог, а вместо этого просто #include придает им C-стиль (скорее, думая о них как о пакетах с отдельными областями).

 INSTALLDIR := build
SRCDIR := src

TARGETS := projA projB
.PHONY: $(TARGETS)
TARGETS_PATH := $(addprefix $(SRCDIR)/, $(TARGETS))
MAKEFILES := $(addsuffix /osx.mak, $(TARGETS_PATH))
# include them somehow?

Для такой настройки, как определено выше, я теперь хочу, чтобы каждая из них $(TARGETS) зависела от release цели соответствующего Makefile (что-то вроде projA: $(SRCDIR)/projA/osx.mak @ release для ProjA, на моем родном языке означающее, что целевая ProjA зависит от успешного выполнения release цели в этом конкретном Makefile).

Есть ли какой-либо способ достичь этого?
Вы можете предложить другие инструменты, помимо GNU make, но makefiles подпроекта уже записаны как makefiles.

Ответ №1:

Взгляните на рекурсивный make.

Вы могли бы сделать что-то вроде,

 SRCDIR := src
TARGETS := projA projB
.PHONY: $(TARGETS)

$(TARGETS):
    cd $(SRCDIR)/$@; $(MAKE) release

1. О, я вижу, это действительно работает! Это своего рода то, что я пробовал сначала, только я установил цели в зависимости от реальных файлов, которые я хотел скопировать. Естественно, поскольку я не мог заставить их зависеть от этих других целей, после первого запуска make просто сказал бы pass, потому что файлы уже были там. Duuh

2. Это похоже на правильный путь, но все еще кажется немного халтурным, поскольку make в конечном итоге вызывает все другие make-файлы, а затем копирует все результаты каждый раз, даже если они не были восстановлены. Меня больше интересует решение, которое позволяет глобальному make-файлу узнавать, изменились ли подпроекты, и копировать только файлы из каждого измененного подпроекта.

3. @Dan: чтобы быть более избирательным, главный makefile должен знать предварительные условия целевого файла, что означает, что ему, вероятно, придется include использовать меньший makefile или, по крайней мере, его часть. Это выполнимо, но вы приближаетесь к нерекурсивному makefile.

4. @Dan: Если вы хотите контролировать процесс копирования, вы можете безоговорочно создать подпроект (для проверки зависимостей), а затем вызвать другое правило, которое копирует файл, только если он изменился с момента последнего копирования.