Re: Чем плох рекурсивный make?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Wed, 1 Oct 2008 15:59:50 +0400:
AC>>>> make, напомню, в отличие от gcc, вызывают не только чтобы собрать цель,
AC>>>> но и чтобы _пере_собрать ее.
AC>>> gcc вызывают не только для того чтобы собрать .o, но и пересобрать .o
AC>>> нет отличий
AC>> gcc вызывают для того, чтобы сделать новый .o _вместо_ старого. Он про
AC>> старый вообще не думает, он его молча затирает. make - думает.
DEO> и что с того что думает? мы что будем различия строить на том о чем
DEO> думает какая-то программа во время работы?
DEO> они каждая думает о своем.
DEO> ладно хорошо другой пример:
DEO> есть у нас makefile из которого вызывается другой makefile, но
DEO> предположим не с программой make а с программой ?make
DEO> рекурсия есть или рекурсии нет?
depends. Если ?make - это скрипт, выполняющий rm -f $1, то нет.
AC>> Если это не отличие, то ты не в курсе, зачем нужен make.
DEO> он нужен чтобы собирать цели, а уже собранные игнорировать.
Отнюдь не игнорировать.
AC>> make как раз усложняет сборку по сравнению с тупым шелловским скриптом.
AC>> Но удешевляет ее за счет этого.
DEO> смотря что считать простотой,
DEO> а так и то и другое - фактически скрипты
Шелловский скрипт unconditional сборки проекта проще соответствующего
мейкфайла. Потому что надо описать только команды сборки, а на
зависимости можно забить.
AC>>> вызов внешнего make - нерекурсивный
AC>>> и ничего не ломает
AC>> Ты не подумал о том, о чем я тебя просил подумать? Или подумал, но не
AC>> понял?
DEO> см пример выше когда make вызывает какой-то другой make :D
Ясно. Не понял. Объяснить?
AC>>> а сколько пакетов собираются с первой попытки но не собираются со
AC>>> второй...
AC>> Это как раз существенно более типичная иллюстрация к recursive make
AC>> considered harmful. Но в натуре, как правило вот ровно к этому.
DEO> хармфул тут в голове макепейсателя а не в самом маке
Скажем так, избежать этих грабель при рекурсивном вызове make гораздо
труднее, чем в заменителях, которые об этой проблеме в курсе. Для того,
чтобы их избежать, надо о них помнить. И в результате все равно
получишь лишние действия.
У make, впрочем, есть и еще одна проблема. Она уже не имеет отношения к
рекурсивному вызову, но ноги ее растут примерно из той же весьма куцей
модели зависимостей, которую он реализует. Ее тоже можно обойти, но это
ВЕСЬМА нетривиально, и разумеется, НИКАК не поддерживается встроенными
правилами (т.е. встроенными пользоваться при этом нельзя). Называется
она "разные аргументы командной строки".
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
If it's there and you can see it---it's real
If it's not there and you can see it---it's virtual
If it's there and you can't see it---it's transparent
If it's not there and you can't see it---you erased it!
IBM poster explaining virtual memory, circa 1978
Reply to: