В первую очередь это письмо обращено к Диме Обухову, который утверждает,
что "все легко, вот тут добавим еще пару зависимостей, и эта задача тоже
решится". С удовольствием увижу присоединившимся к контесту Алексея
Чеусова, с BSD make (видимо, pmake, чтобы было топичнее - но если что, я
и netbsd найду). Остальные желающие себя попробовать - тоже welcome.
Более того, в дальнейшем сильно не welcome рассуждения "вы не умеете
пользоваться make" от тех, кто не продемонстрировал своего умения в этой
задаче. Она сравнительно проста.
Итак.
Дерево проекта:
dirA
Makefile
dirB
Makefile
b.c
c.c
Makefile в dirA собирает пакет. Допустим, для простоты a.tar.gz. Он
туда кладет dirB/b и dirB/c, которые собирает путем компиляции из b.c и
c.c соответственно dirB/Makefile. То есть, внимание, результатом работы
dirB/Makefile (тем самым бинарником, о котором ты говоришь выше)
являются только dirB/b и dirB/c. dirB/b.c НЕ является результатом его
работы. И нафиг не нужен при пакетировании.
Все очень просто.
Собственно задача: написать мейкфайлы так, чтобы каждый выполнял свою
работу (dirB/Makefile создавал dirB/b и dirB/c, dirA/Makefile -
a.tar.gz). Чтобы при этом при изменении b.c и запуске make all
(внимание на имя цели!) в dirA пересобирался dirB/b и a.tar.gz. А
dirB/c не пересобирался (поскольку c.c не менялся). Чтобы при этом
сборка работала, разумеется, путем запуска make all в dirA "с чистого
листа", т.е. при отсутствии в dirB бинарников. И чтобы при запуске make
all (внимание, то же самое имя цели!) в dirB собирались b и с. Тоже
соответственно зависимостям (ну, само по себе это просто).
Дополнительные файлы в проект добавлять можно (я, ага, хочу, чтобы
задача все же имела решение).
Почему имя цели одинаковое? А мы моделируем debian/rules, в нем имена
целей, используемых системой сборки пакетов (следовательно, не
подлежащие замене) с легкостью совпадают с именами целей из orig.tar.gz
(тоже, соответственно, замене не подлежащими). А дополнительный цимес
задаче оно доставляет...
make, поскольку мы в d-r, по умолчанию гнутый.
Большие знатоки заменителей могут показать решение той же задачи на
заменителях. Было бы интересно посмотреть.
Решение считается имеющимся, если я в нем ошибок не нашел (т.е. не сумел
предъявить последовательность команд, которая демонстрирует, что задача
не решена). А НЕ если в своем решении не сумел найти ошибок его автор.
Я просто об эту задачу (естественно, в куда более расширенном варианте,
там несколько директорий не по прихоти, а по делу) уже обнаслаждался по
самое не могу. Если кто-то считает, что я плохо умею пользоваться make,
а на самом деле там все легко - подтвердите свое заявление фактами,
пожалуйста.
Для невнимательных: задача решение имеет. В такой вот простенькой
конфигурации - даже не слишком сложное, по крайней мере на гнутом мейке.
Но крайне хреново масштабируется.
Других тараканов make (их тоже есть) я в нее включать не стал.
Тем, кто справится с этой задачей, и будет еще пассионарен, могу
предложить ту, об которую я таки обломал зубы (отслеживание актуальных
зависимостей от инклудов, в полной постановке).
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: [EMAIL PROTECTED]
kernel bug (англ.) - ядрёна вошь
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
