о у меня примерно такая шняга в одном из проектов есть, примерно так и
работает (архив создается с бинарником и из исходников),
работа твоего примера (я вместо gcc cp использовал чтобы не париться с
ошибками):
nbw:[~/test.mk]$ touch B/b.c
nbw:[~/test.mk]$ make -C A all
make: Entering directory `/home/dimka/test.mk/A'
make -C ../B
make[1]: Entering directory `/home/dimka/test.mk/B'
cp ./b.c b
make[1]: Leaving directory `/home/dimka/test.mk/B'
tar -czvf ../a.tgz ../B/c ../B/b
tar: Удаляется начальный `../' из имен объектов
../B/c
../B/b
make: Leaving directory `/home/dimka/test.mk/A'
nbw:[~/test.mk]$ make -C A all
make: Entering directory `/home/dimka/test.mk/A'
make: Цель `all' не требует выполнения команд.
make: Leaving directory `/home/dimka/test.mk/A'
nbw:[~/test.mk]$ touch B/c.c
nbw:[~/test.mk]$ make -C A all
make: Entering directory `/home/dimka/test.mk/A'
make -C ../B
make[1]: Entering directory `/home/dimka/test.mk/B'
cp ./c.c c
make[1]: Leaving directory `/home/dimka/test.mk/B'
tar -czvf ../a.tgz ../B/c ../B/b
tar: Удаляется начальный `../' из имен объектов
../B/c
../B/b
make: Leaving directory `/home/dimka/test.mk/A'
nbw:[~/test.mk]$ make -C A all
make: Entering directory `/home/dimka/test.mk/A'
make: Цель `all' не требует выполнения команд.
make: Leaving directory `/home/dimka/test.mk/A'
и так выглядит:
$ cat include.mk
$(DIR_SRC)/b: $(DIR_SRC)/b.c
$(DIR_SRC)/c: $(DIR_SRC)/c.c
$ cat A/Makefile
DIR_SRC = ../B
include ../include.mk
all: ../a.tgz
../a.tgz: $(DIR_SRC)/c $(DIR_SRC)/b
tar -czvf $@ $^
$(DIR_SRC)/c:
make -C $(DIR_SRC)
$(DIR_SRC)/b:
make -C $(DIR_SRC)
$ cat B/Makefile
DIR_SRC = .
all: $(DIR_SRC)/b $(DIR_SRC)/c
include ../include.mk
$(DIR_SRC)/b:
cp $< $@
$(DIR_SRC)/c:
cp $< $@
.PHONY: all
насколько я понимаю начнешь сейчас придираться к наличию include.mk?
но вот в чем фишка: в рамках одного проекта такой файл составляется
легко (можно даже поиграться с его автогенерацией, например make dep
устроить)
сгенерить include.mk можно разными способами, например
make -r -p
а в рамках разных проектов (навроде собираем архив) такое вообще редко
нужно, например ДАННАЯ задача может решаться так:
A/Makefile:
all: ../a.tgz
../a.tgz: $(DIR_SRC)/c $(DIR_SRC)/b
make -C ../B
tar -czvf $@ $^
и ничего страшного что make -C ../B вызывается постоянно, поскольку он
ничего не делает.
Да имеется проблема в том что список зависимостей сгенерить иногда
не так просто в пределе пишем его руками (это имхо сложные случаи, когда
как раз автор B/Makefile юзает рекурсии), но эта проблема не растет от
"рекурсивности" а от криворукости макеписателя :)
On 19:41 Wed 01 Oct , Artem Chuprina wrote:
AC> В первую очередь это письмо обращено к Диме Обухову, который утверждает,
AC> что "все легко, вот тут добавим еще пару зависимостей, и эта задача тоже
AC> решится". С удовольствием увижу присоединившимся к контесту Алексея
AC> Чеусова, с BSD make (видимо, pmake, чтобы было топичнее - но если что, я
AC> и netbsd найду). Остальные желающие себя попробовать - тоже welcome.
AC> Более того, в дальнейшем сильно не welcome рассуждения "вы не умеете
AC> пользоваться make" от тех, кто не продемонстрировал своего умения в этой
AC> задаче. Она сравнительно проста.
AC> Итак.
AC> Дерево проекта:
AC> dirA
AC> Makefile
AC> dirB
AC> Makefile
AC> b.c
AC> c.c
AC> Makefile в dirA собирает пакет. Допустим, для простоты a.tar.gz. Он
AC> туда кладет dirB/b и dirB/c, которые собирает путем компиляции из b.c и
AC> c.c соответственно dirB/Makefile. То есть, внимание, результатом работы
AC> dirB/Makefile (тем самым бинарником, о котором ты говоришь выше)
AC> являются только dirB/b и dirB/c. dirB/b.c НЕ является результатом его
AC> работы. И нафиг не нужен при пакетировании.
AC> Все очень просто.
AC> Собственно задача: написать мейкфайлы так, чтобы каждый выполнял свою
AC> работу (dirB/Makefile создавал dirB/b и dirB/c, dirA/Makefile -
AC> a.tar.gz). Чтобы при этом при изменении b.c и запуске make all
AC> (внимание на имя цели!) в dirA пересобирался dirB/b и a.tar.gz. А
AC> dirB/c не пересобирался (поскольку c.c не менялся). Чтобы при этом
AC> сборка работала, разумеется, путем запуска make all в dirA "с чистого
AC> листа", т.е. при отсутствии в dirB бинарников. И чтобы при запуске make
AC> all (внимание, то же самое имя цели!) в dirB собирались b и с. Тоже
AC> соответственно зависимостям (ну, само по себе это просто).
AC> Дополнительные файлы в проект добавлять можно (я, ага, хочу, чтобы
AC> задача все же имела решение).
AC> Почему имя цели одинаковое? А мы моделируем debian/rules, в нем имена
AC> целей, используемых системой сборки пакетов (следовательно, не
AC> подлежащие замене) с легкостью совпадают с именами целей из orig.tar.gz
AC> (тоже, соответственно, замене не подлежащими). А дополнительный цимес
AC> задаче оно доставляет...
AC> make, поскольку мы в d-r, по умолчанию гнутый.
AC> Большие знатоки заменителей могут показать решение той же задачи на
AC> заменителях. Было бы интересно посмотреть.
AC> Решение считается имеющимся, если я в нем ошибок не нашел (т.е. не сумел
AC> предъявить последовательность команд, которая демонстрирует, что задача
AC> не решена). А НЕ если в своем решении не сумел найти ошибок его автор.
AC> Я просто об эту задачу (естественно, в куда более расширенном варианте,
AC> там несколько директорий не по прихоти, а по делу) уже обнаслаждался по
AC> самое не могу. Если кто-то считает, что я плохо умею пользоваться make,
AC> а на самом деле там все легко - подтвердите свое заявление фактами,
AC> пожалуйста.
AC> Для невнимательных: задача решение имеет. В такой вот простенькой
AC> конфигурации - даже не слишком сложное, по крайней мере на гнутом мейке.
AC> Но крайне хреново масштабируется.
AC> Других тараканов make (их тоже есть) я в нее включать не стал.
AC> Тем, кто справится с этой задачей, и будет еще пассионарен, могу
AC> предложить ту, об которую я таки обломал зубы (отслеживание актуальных
AC> зависимостей от инклудов, в полной постановке).
--
... mpd is off
. ''`. Dmitry E. Oboukhov
: :’ : email: unera@debian.org jabber://UNera@uvw.ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Attachment:
signature.asc
Description: Digital signature