[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: make contest



Dmitry E. Oboukhov -> debian-russian@lists.debian.org  @ Wed, 1 Oct 2008 22:30:42 +0400:

 DEO> о у меня примерно такая шняга в одном из проектов есть, примерно так и
 DEO> работает (архив создается с бинарником и из исходников),

 DEO> работа твоего примера (я вместо gcc cp использовал чтобы не париться с
 DEO> ошибками):

 DEO> nbw:[~/test.mk]$ touch B/b.c
 DEO> nbw:[~/test.mk]$ make -C A all
 DEO> make: Entering directory `/home/dimka/test.mk/A'
 DEO> make -C ../B
 DEO> make[1]: Entering directory `/home/dimka/test.mk/B'
 DEO> cp ./b.c b
 DEO> make[1]: Leaving directory `/home/dimka/test.mk/B'
 DEO> tar -czvf ../a.tgz ../B/c ../B/b
 DEO> tar: Удаляется начальный `../' из имен объектов
 DEO> ../B/c
 DEO> ../B/b
 DEO> make: Leaving directory `/home/dimka/test.mk/A'
 DEO> nbw:[~/test.mk]$ make -C A all
 DEO> make: Entering directory `/home/dimka/test.mk/A'
 DEO> make: Цель `all' не требует выполнения команд.
 DEO> make: Leaving directory `/home/dimka/test.mk/A'
 DEO> nbw:[~/test.mk]$ touch B/c.c
 DEO> nbw:[~/test.mk]$ make -C A all
 DEO> make: Entering directory `/home/dimka/test.mk/A'
 DEO> make -C ../B
 DEO> make[1]: Entering directory `/home/dimka/test.mk/B'
 DEO> cp ./c.c c
 DEO> make[1]: Leaving directory `/home/dimka/test.mk/B'
 DEO> tar -czvf ../a.tgz ../B/c ../B/b
 DEO> tar: Удаляется начальный `../' из имен объектов
 DEO> ../B/c
 DEO> ../B/b
 DEO> make: Leaving directory `/home/dimka/test.mk/A'
 DEO> nbw:[~/test.mk]$ make -C A all
 DEO> make: Entering directory `/home/dimka/test.mk/A'
 DEO> make: Цель `all' не требует выполнения команд.
 DEO> make: Leaving directory `/home/dimka/test.mk/A'

 DEO> и так выглядит:

 DEO> $ cat include.mk
 DEO>     $(DIR_SRC)/b: $(DIR_SRC)/b.c
 DEO>     $(DIR_SRC)/c: $(DIR_SRC)/c.c

 DEO> $ cat A/Makefile 
 DEO>     DIR_SRC         = ../B
 DEO>     include ../include.mk

 DEO>     all: ../a.tgz

 DEO>     ../a.tgz: $(DIR_SRC)/c $(DIR_SRC)/b
 DEO>             tar -czvf $@ $^

 DEO>     $(DIR_SRC)/c:
 DEO>             make -C $(DIR_SRC)

 DEO>     $(DIR_SRC)/b:
 DEO>             make -C $(DIR_SRC)

 DEO> $ cat B/Makefile 
 DEO>     DIR_SRC         = .

 DEO>     all: $(DIR_SRC)/b $(DIR_SRC)/c

 DEO>     include ../include.mk

 DEO>     $(DIR_SRC)/b:
 DEO>             cp $< $@

 DEO>     $(DIR_SRC)/c:
 DEO>             cp $< $@
 DEO>     .PHONY: all

 DEO> насколько я понимаю начнешь сейчас придираться к наличию include.mk?
 DEO> но вот в чем фишка: в рамках одного проекта такой файл составляется
 DEO> легко (можно даже поиграться с его автогенерацией, например make dep
 DEO> устроить)
 DEO> сгенерить include.mk можно разными способами, например
 DEO> make -r -p

Нет, я, в общем, имел в виду похожий инклуд.  Нет, не такой кривой,
попрямее.  Я в первом своем ответе на ответ Станислава указал, как
именно сломается твоя конструкция в реальной жизни, и как ее починить.

Кривизна твоего решения в том, что ты половину B/Makefile дублируешь в
A/Makefile, да еще и делаешь это с ошибками.  Нет, на _данной_ задаче
они еще не вылезают.  Они вылезут на реальной.

А еще сравни размер своего решения с решением Юры Козлова.  А потом - с
размером решения на sh без make с той же функциональностью :-)
Понятность и шанс ошибиться тоже сравни.

Ну, у тебя тут еще есть пара тараканов (так, по-хорошему, правило для
создания $(DIR_SRC)/b в A должно быть не make -C $(DIR_SRC), а make -C
$(DIR_SRC) ./b), но это, опять же, лечится указанным мной способом.

 DEO> а в рамках разных проектов (навроде собираем архив) такое вообще редко
 DEO> нужно, например ДАННАЯ задача может решаться так:

 DEO> A/Makefile:

 DEO> all: ../a.tgz

 DEO> ../a.tgz: $(DIR_SRC)/c $(DIR_SRC)/b
 DEO>     make -C ../B
 DEO>     tar -czvf $@ $^

 DEO> и ничего страшного что make -C ../B вызывается постоянно, поскольку он
 DEO> ничего не делает.

А как сломается эта - написал Станислав.  Я ему сперва возразил, потому
что не понял, что он отвечал именно на этот вариант.  Вернее, для начала
оно сломается при попытке make all в A "с чистого листа".  Цимес с
"добавим зависимость" в том, что как только ты написал зависимость от c
и b, тебе надо озаботиться, чтобы мейкфайл в A знал, как их собирать.
Потому что решение он будет принимать ДО того, как выполнится make -C ../B.

Насчет "легко" ты свою ошибку понял, или постепенно приближать задачу к
реальной?  ("А теперь в B надо вот это сделать чуть похитрее...")

 DEO> Да имеется проблема в том что список зависимостей сгенерить иногда
 DEO> не так просто в пределе пишем его руками (это имхо сложные случаи,
 DEO> когда как раз автор B/Makefile юзает рекурсии), но эта проблема не
 DEO> растет от "рекурсивности" а от криворукости макеписателя :)

"Сгенерить список зависимостей" - это как раз задача, которую я в полной
постановке решить не сумел.  Ставить?

Нет, руками не годится - оно зависит, в частности, от того, для какой
системы мы в данный момент собираем проект.  Впрочем, за предложение
руками писать зависимости от сишных хедеров (из соседних директорий,
ага), мне кажется, можно расстреливать без суда и следствия.

-- 
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru

/итд/почтопосылалка.нстрк (c)


Reply to: