Re: Чем плох рекурсивный make?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 2 Oct 2008 18:10:28 +0400:
AC>> Ну, это лучше, да. Причем мне, честно говоря, сходу даже было
AC>> непонятно, почему работает первое решение... Пришлось гонять make -d и
AC>> разбираться.
AC>> А теперь вот так вот для каждой переменной, которую можно указать
AC>> мейкфайлу, и у каждой цели, на сборку которой эта переменная влияет...
AC>> И пару раз ошибиться...
AC>> Нет, все-таки такие вещи должен отслеживать сам инструмент...
DEO> если учесть что данная задача как правило редкая (обычно debug
DEO> включается в чем-то вроде configure),
У админа или мейнтейнера пакета. Разработчику оно надо гораздо чаще.
И нет там никакого configure.
Кроме того, там отнюдь не только debug. Там еще и текущая платформа до
кучи (ага, автор makepp в курсе, что бывает такая схема разработки и
тестирования...)
DEO> то если сам инструмент будет пересобирать проект в зависимости от
DEO> смены переменных, то он рискует начать пересобирать его от простой
DEO> правки makefile в местах независящих от каких-либо переменных. я
DEO> не знаю как он должен работать чтобы 1. услужливость не переходила
DEO> в навязчивость с которой придется бороться 2. без внешних файлов в
DEO> которых хранить состояние предыдущей сборки
Условие "без внешних файлов" не ставится. Пусть с внешними, если ему
так удобно. makepp вон удобно. Хочется "без геморроя и провокации
ошибок разработчика".
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Кто первый встал, того и грабли
Д. Белявский
Reply to: