Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 2 Oct 2008
11:10:51 +0400:
AC>> Примерно с той же, блин, целью сделан и configure. Непонятно
AC>> только, нафига он генерирует развесистый мейкфайл вместо тупого
AC>> sh-скрипта - все равно в половине случаев от того make там один
AC>> вред.
DEO> не почему, configure перезапускаем только когда меняется что-то в
DEO> количестве исходников скажем итп а сама отладка работает на make
DEO> то есть поправил файл - make, поправил - make, добавил - configure -
DEO> make
DEO> итп
Там правка правке рознь. Добавил #include - уже вынь да положь configure.
AC>> На самом деле, естественно, не "такая и задумана", а "проще забить, чем
AC>> вылечить".
DEO> лечение предполагает либо экстракт депендсов из авторского makefile,
DEO> либо дубликат их во внешнем, либо правку авторского.
DEO> первый пункт в каком-то *make удобно реализован? только так чтобы сборка
DEO> не становилась узкоспециализированной
Насколько я знаю, задача добычи зависимостей из makefile как минимум
весьма сложна. Подозреваю, что неразрешима.
AC>> Что для данного применения плохо, но приемлемо. Для целей
AC>> разработки же - скорее неприемлемо.
DEO> для целей разработки есть авторский makefile :)
"Я и есть автор". Переделанная цитата из известного анекдота.
DEO> то есть если ты вызываешь внешний make, то это надо рассматривать как 1
DEO> единичное действие.
DEO> а если ты хочешь чтобы часть действий одного была и в другом это уже
DEO> получается ты хочешь 1 make использовать как библиотеку к другому
DEO> тут конечно получаются костыли и подпорки... что делать?
Менять make на альтернативу, в которой при дизайне это учтено.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
