AC> Блин. Ты хочешь доказать мне, что можно придумать пример, где AC> рекурсивный вызов make не составляет проблем? Не вопрос, я и сам могу.
AC> Вопрос в том, что в типичном случае проблемы будут. А в том, где не
AC> будет, использование make - это из пушек по воробьям.
AC> Или тебе настолько не нравится слово "рекурсивный", что ты не можешь
AC> найти в себе сил выяснить, что оно значит в контексте обсуждаемой фразы
AC> из четырех английских слов?
[*] я вижу что описываемые проблемы растут не из "кривости" или
"рекурсивности" make а из неправильного применения инструмента.
AC>>> Шелловский скрипт unconditional сборки проекта проще соответствующего
AC>>> мейкфайла. Потому что надо описать только команды сборки, а на
AC>>> зависимости можно забить.
AC>> если ты на зависимости забьешь то у тебя не соберется
AC> Соберется. Я две строчки местами поменяю (несколько раз), и соберется.
ну так ты удовлетворишь зависимости этими двумя строчками потому и
соберется
AC>> а и shell'овским скриптом тоже можно смотреть на даты файлов и
AC>> сравнивать их.
AC>> разницы тут ровно столько что в одном языке одно действие сделать проще
AC>> чем в другом
AC> Ты слово unconditional не смог прочесть или найти в словаре?
и что это слово? (*)
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> Вопрос. Какая версия будет в пакете в результате?
здесь как видно не собирался никто сделать повторную сборку ибо не нужна
понадобится - configure вынесется в отдельную цель и будет результат
всегда правильный
а наложение патчей на собственно make'ы, да потребует сделать clean, но
эту проблему можно будет решить поставив зависимость на сам Makefile.
где проблема-то? в том что решалась одна задача, а захотелось решить
попутно и другую? так давай ее впишем в ТЗ и решим? добавится пара целей
и депендсов и ничего не изменится :)
AC> Для особо невнимательных сразу ответ. Старая. В смысле - та, которая
AC> была, а не обновленная. Оно просто не попытается ничего инсталлировать.
AC> Почему? Да потому что ему неоткуда знать, что там что-то изменилось.
AC> Оно видит только, что есть файл install-stamp, а раз он есть, делать
AC> ничего не надо.
ну да, это ведь такая работа и задумана.
AC> Можно его изменить так, чтобы он гарантированно каждый раз собирал
AC> свежую версию.
смотри, если мы не делаем configure, а делаем
make
изменили что-то
make
изменили что-то
make
то оно ж в исходной (авторской) системе сборки отлично итеративно
собирает/линкует только изменения.
то есть поменяв зависимость (что типично для языка make) с install-stamp
на собираемые бинарники мы решим и ту задачу что тебе нужна (она была
просто не нужна в рамках этого make)
задачу мы решаем все теми же средствами make и что тут ломается
в идеологии непонятно.
AC> Но - фактически ценой отказа от функциональности make по
AC> анализу "что надо собирать, а что - нет".
а где отказ?
смотри, авторский make собирает N бинарников и M либ
в debian/rules мы вместо того чтобы ставить N+M зависимостей, нарисовали
один install-stamp, но можно на install-stamp просто в зависимости
прописать все бинарники и будет то же самое, только с полноценной
ресборкой (я думаю это появится как только майнтенеру понадобится
поотлаживать что-то в коде, а пока ненужно)
AC> Терминология используется не твоя, а авторов make. Dixi.
ну хорошо, рекурсивный
избежать легко учетом зависимостей
внешный make - компилятор
то что он собирает является депендсом для того что собирает данный мейк
что не так?
AC> Нет. Вон выше пример разжеван в деталях. Ровно такая ситуация, даже
AC> без либы2.
этот пример как раз пример недоделанного (до решения _и_ этой задачи)
make
доделка сводится к вводу нескольких зависимостей
AC> Повторяю. Специально писать надо makefile1, а не makefile3. Т.е. в
AC> данном случае правками в debian/rules это не лечится.
именно лечится
установкой (заменой) зависимости install-stamp на бинарники (в
простейшем случае видимо достаточно будет зависеть от одного из
бинарников, в идеальном случае - от всех)
AC> А на практике, естественно, этого никто делать и не пытается (особенно,
AC> если makefile1 сгенерирован, а не руками писан), а делают make -C dir.
и после make -C dir получают собранными те цели что собирает этот make.
в данном случае эти цели заменены на install-stamp
--
... mpd is off
. ''`. Dmitry E. Oboukhov
: :’ : email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED]
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
signature.asc
Description: Digital signature
