Re: Чем плох рекурсивный make?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 2 Oct 2008 12:53:16 +0400:
AC>> Там правка правке рознь. Добавил #include - уже вынь да положь configure.
DEO> смотря какой include :)
DEO> если на себя же (свой проект) то да :)
Ну, этого уже достаточно. Т.е. какие именно операции редактирования
могут обойтись без configure, а какие нет - определяется уже совсем не
так просто...
DEO> а если на тот что в /usr лежит, то запуск configure можно в долгий
DEO> ящик откладывать :)
Если на тот, что в /usr, то надо, вообще говоря, немедленно править
configure.in, а не просто запускать configure...
AC>>> первый пункт в каком-то *make удобно реализован? только так чтобы сборка
AC>>> не становилась узкоспециализированной
AC>> Насколько я знаю, задача добычи зависимостей из makefile как минимум
AC>> весьма сложна. Подозреваю, что неразрешима.
DEO> подозреваю что разрешима
DEO> поскольку make эти зависимости строит, то есть можно ее допатчить чтобы
DEO> она их выводила в удобоваримом виде (она и сейчас умеет их вывести, но
DEO> рекурсивные ревызовы сейчас она не умеет)
Скажем так, для этого придется провести сборку. На самом деле, да. dry
run выдает ненадежный результат.
AC>>>> Что для данного применения плохо, но приемлемо. Для целей
AC>>>> разработки же - скорее неприемлемо.
AC>>> для целей разработки есть авторский makefile :)
AC>> "Я и есть автор". Переделанная цитата из известного анекдота.
DEO> когда ты автор сделать depends.mk тебе труда не составит
В нетривиальном случае - еще как составит. Реально, да. Но труда много.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Вот .NET и Mono - это современные технологии. В смысле - сырые и глюкавые.
Victor Wagner в <cisnd1$qtc$4@wagner.wagner.home>
Reply to: