AC>>> Или тебе настолько не нравится слово "рекурсивный", что ты не можешь AC>>> найти в себе сил выяснить, что оно значит в контексте обсуждаемой фразы AC>>> из четырех английских слов? AC>> [*] я вижу что описываемые проблемы растут не из "кривости" или AC>> "рекурсивности" make а из неправильного применения инструмента. AC> Можно сказать и так. Только тогда во всей идее .deb он применяется AC> неправильно, во-вторых, а во-первых, ты пробовал его применить AC> правильно? Я пробовал. Можно. Но с ТАКИМ геморроем... да с геморроем, но я везде где ковырялся и пробовал геморрой обычно начинается там где появляется рекурсивность (реальная) вызовов make а в других случаях для deb-пакетов вроде dep-s'ы можно так или иначе вытащить из оригинального make :) AC>>> Соберется. Я две строчки местами поменяю (несколько раз), и соберется. AC>> ну так ты удовлетворишь зависимости этими двумя строчками потому и AC>> соберется AC> Именно. Но я это сделаю один раз. Более того, я это сделаю сразу, при AC> первом написании скрипта. В _моем_ скрипте их переставлять не AC> придется. тогда непонятно к чему эта подветка дискуссии :) AC>>> Изменяем проект (допустим, накладываем патч). Даже, допустим, собираем AC>>> результат. Там же, в проекте. Запускаем debian/rules install, дабы AC>>> заново собрать пакет (на самом деле, естественно, запускаем binary, а AC>>> оно позовет install - там это будет в еще два шага, я их не привел). AC>>> Вопрос. Какая версия будет в пакете в результате? AC>> здесь как видно не собирался никто сделать повторную сборку ибо не нужна AC> В модели pbuilder - не нужна, он каждый раз все удаляет нах. Но AC> непонятно тогда, зачем там make. Внимание. Почему - понятно. AC> Непонятно, зачем. да действительно непонятно :) исторический рудимент buildd всегда начинает работу с clean :) AC> Примерно с той же, блин, целью сделан и configure. Непонятно только, AC> нафига он генерирует развесистый мейкфайл вместо тупого sh-скрипта - все AC> равно в половине случаев от того make там один вред. не почему, configure перезапускаем только когда меняется что-то в количестве исходников скажем итп а сама отладка работает на make то есть поправил файл - make, поправил - make, добавил - configure - make итп AC> На самом деле, естественно, не "такая и задумана", а "проще забить, чем AC> вылечить". лечение предполагает либо экстракт депендсов из авторского makefile, либо дубликат их во внешнем, либо правку авторского. первый пункт в каком-то *make удобно реализован? только так чтобы сборка не становилась узкоспециализированной AC> Что для данного применения плохо, но приемлемо. Для целей AC> разработки же - скорее неприемлемо. для целей разработки есть авторский makefile :) AC> После того, как ты мне это предъявишь в качестве решения, я поменяю в AC> проекте один сишник. Он не пересоберется, потому что для бинарников-то AC> зависимости не прописаны. ну так их надо выковырять из авторского :) вот если в нем нет рекурсий то это можно у make попросить полный список их (правда там приходится отсортировывать все ненужное) AC> Ты попробуй сделать - сам поймешь. Если не поймешь - я подскажу AC> последовательность команд, демонстрирующую проблему. я то понимаю, просто ты пытаешься соединить две задачи а я говорю что это неправильный подход. то есть если ты вызываешь внешний make, то это надо рассматривать как 1 единичное действие. а если ты хочешь чтобы часть действий одного была и в другом это уже получается ты хочешь 1 make использовать как библиотеку к другому тут конечно получаются костыли и подпорки... что делать? AC> Сделай. пример выше -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: unera@debian.org jabber://UNera@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Attachment:
signature.asc
Description: Digital signature