Re: Чем плох рекурсивный make?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Wed, 1 Oct 2008 18:17:20 +0400:
AC>> Блин. Ты хочешь доказать мне, что можно придумать пример, где
AC>> рекурсивный вызов make не составляет проблем? Не вопрос, я и сам могу.
AC>> Вопрос в том, что в типичном случае проблемы будут. А в том, где не
AC>> будет, использование make - это из пушек по воробьям.
AC>> Или тебе настолько не нравится слово "рекурсивный", что ты не можешь
AC>> найти в себе сил выяснить, что оно значит в контексте обсуждаемой фразы
AC>> из четырех английских слов?
DEO> [*] я вижу что описываемые проблемы растут не из "кривости" или
DEO> "рекурсивности" make а из неправильного применения инструмента.
Можно сказать и так. Только тогда во всей идее .deb он применяется
неправильно, во-вторых, а во-первых, ты пробовал его применить
правильно? Я пробовал. Можно. Но с ТАКИМ геморроем...
AC>>>> Шелловский скрипт unconditional сборки проекта проще соответствующего
AC>>>> мейкфайла. Потому что надо описать только команды сборки, а на
AC>>>> зависимости можно забить.
AC>>> если ты на зависимости забьешь то у тебя не соберется
AC>> Соберется. Я две строчки местами поменяю (несколько раз), и соберется.
DEO> ну так ты удовлетворишь зависимости этими двумя строчками потому и
DEO> соберется
Именно. Но я это сделаю один раз. Более того, я это сделаю сразу, при
первом написании скрипта. В _моем_ скрипте их переставлять не
придется.
AC>>> а и shell'овским скриптом тоже можно смотреть на даты файлов и
AC>>> сравнивать их.
AC>>> разницы тут ровно столько что в одном языке одно действие сделать проще
AC>>> чем в другом
AC>> Ты слово unconditional не смог прочесть или найти в словаре?
DEO> и что это слово? (*)
И то, что если механизм проверки условия пересборки выключить, то make
становится скорее источником ошибок, чем удобным инструментом.
AC>> Объясняю. Берем (для примера урезанный, существенное сохранено) вариант
AC>> того самого debian/rules, который тебе вроде как нравился.
AC>> install: configure install-stamp
AC>> install-stamp:
AC>> make -C .. install DESTDIR=debian/tmp
AC>> touch $@
AC>> Выполнили один раз. Результат, допустим, не понравился.
AC>> Изменяем проект (допустим, накладываем патч). Даже, допустим, собираем
AC>> результат. Там же, в проекте. Запускаем debian/rules install, дабы
AC>> заново собрать пакет (на самом деле, естественно, запускаем binary, а
AC>> оно позовет install - там это будет в еще два шага, я их не привел).
AC>> Вопрос. Какая версия будет в пакете в результате?
DEO> здесь как видно не собирался никто сделать повторную сборку ибо не нужна
В модели pbuilder - не нужна, он каждый раз все удаляет нах. Но
непонятно тогда, зачем там make. Внимание. Почему - понятно.
Непонятно, зачем.
Примерно с той же, блин, целью сделан и configure. Непонятно только,
нафига он генерирует развесистый мейкфайл вместо тупого sh-скрипта - все
равно в половине случаев от того make там один вред.
DEO> понадобится - configure вынесется в отдельную цель и будет результат
DEO> всегда правильный
Там вынесено. Ты туда загляни. Те же яйца, почти дословно.
DEO> а наложение патчей на собственно make'ы, да потребует сделать
DEO> clean, но эту проблему можно будет решить поставив зависимость на
DEO> сам Makefile.
DEO> где проблема-то? в том что решалась одна задача, а захотелось
DEO> решить попутно и другую? так давай ее впишем в ТЗ и решим?
DEO> добавится пара целей и депендсов и ничего не изменится :)
Давай ты мне продемонстрируешь ее решение? Я, видишь ли, пробовал...
AC>> Для особо невнимательных сразу ответ. Старая. В смысле - та, которая
AC>> была, а не обновленная. Оно просто не попытается ничего инсталлировать.
AC>> Почему? Да потому что ему неоткуда знать, что там что-то изменилось.
AC>> Оно видит только, что есть файл install-stamp, а раз он есть, делать
AC>> ничего не надо.
DEO> ну да, это ведь такая работа и задумана.
Если ты полагаешь, что такая и задумана - я могу тебе показать проблему
и внутри debian/rules. Этот конкретный написан так, что они там и без
рекурсивного вызова make есть.
На самом деле, естественно, не "такая и задумана", а "проще забить, чем
вылечить". Что для данного применения плохо, но приемлемо. Для целей
разработки же - скорее неприемлемо.
AC>> Можно его изменить так, чтобы он гарантированно каждый раз собирал
AC>> свежую версию.
DEO> смотри, если мы не делаем configure, а делаем
DEO> make
DEO> изменили что-то
DEO> make
DEO> изменили что-то
DEO> make
DEO> то оно ж в исходной (авторской) системе сборки отлично итеративно
DEO> собирает/линкует только изменения.
DEO> то есть поменяв зависимость (что типично для языка make) с install-stamp
DEO> на собираемые бинарники мы решим и ту задачу что тебе нужна (она была
DEO> просто не нужна в рамках этого make)
Ты попробуй. Покажи решение. Я тебе продемонстрирую, если сам не
сообразишь по дороге, где в нем проблема.
DEO> смотри, авторский make собирает N бинарников и M либ
DEO> в debian/rules мы вместо того чтобы ставить N+M зависимостей,
DEO> нарисовали один install-stamp, но можно на install-stamp просто в
DEO> зависимости прописать все бинарники и будет то же самое, только с
DEO> полноценной ресборкой (я думаю это появится как только майнтенеру
DEO> понадобится поотлаживать что-то в коде, а пока ненужно)
Вот это - ближе. Но в этом варианте это будет для начала тот самый
случай, когда не собирается с первого раза (потому что, натурально,
файлов нету, а правила для их сборки - в другом мейкфайле). Дальше ты
понесешь в debian/rules правило
dir/%:
make -C dir $@
После того, как ты мне это предъявишь в качестве решения, я поменяю в
проекте один сишник. Он не пересоберется, потому что для бинарников-то
зависимости не прописаны.
Дальше объяснять, или нужна наглядная демонстрация?
AC>> Терминология используется не твоя, а авторов make. Dixi.
DEO> ну хорошо, рекурсивный
DEO> избежать легко учетом зависимостей
Предъявите.
DEO> внешный make - компилятор
DEO> то что он собирает является депендсом для того что собирает данный мейк
DEO> что не так?
Ты попробуй сделать - сам поймешь. Если не поймешь - я подскажу
последовательность команд, демонстрирующую проблему.
make в качестве компилятора плох как раз тем, что шибко умный :-)
AC>> Нет. Вон выше пример разжеван в деталях. Ровно такая ситуация, даже
AC>> без либы2.
DEO> этот пример как раз пример недоделанного (до решения _и_ этой задачи)
DEO> make
DEO> доделка сводится к вводу нескольких зависимостей
AC>> Повторяю. Специально писать надо makefile1, а не makefile3. Т.е. в
AC>> данном случае правками в debian/rules это не лечится.
DEO> именно лечится
DEO> установкой (заменой) зависимости install-stamp на бинарники (в
DEO> простейшем случае видимо достаточно будет зависеть от одного из
DEO> бинарников, в идеальном случае - от всех)
Сделай.
AC>> А на практике, естественно, этого никто делать и не пытается (особенно,
AC>> если makefile1 сгенерирован, а не руками писан), а делают make -C dir.
DEO> и после make -C dir получают собранными те цели что собирает этот make.
DEO> в данном случае эти цели заменены на install-stamp
С соответствующими проблемами в комплекте.
Дальше - отдельным письмом. Прошу не отвечать на это, пока не
разберешься с тем.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
/итд/почтопосылалка.нстрк (c)
Reply to: