Re: make contest
Aleksey Cheusov -> debian-russian@lists.debian.org @ Thu, 02 Oct 2008 16:50:27 +0300:
AC>>> Задача стояла построить _зависящую_ цель (пакет) при измениях в
AC>>> исходных файлах _зависимых_ целей (конкретные программы). Эта
AC>>> задача решена.
>> Задача подразумевала некоторую вполне конкретную раскладку по
>> директориям. А не как понравится тебе.
AC> Извини подвинься. Вот уж каталоги я будут делать так, как удобно мне :)
AC> В идеологии mk scripts: один проект (екзешник или библиотека) -
AC> один каталог. Можно сделать как угодно, но оно того не стоит.
AC> И это ОЧЕНЬ удобно.
Нет, если ты можешь _естественно_ организовать проект по схеме "один
проект - один файл на выходе", то да, наверное...
Но это, насколько я могу понять, исключает unit tests (там по жизни
несколько бинарников, да еще с шансами собираться и работать на разных
платформах). Делать отдельный проект ("вот это - хрень, а вот это -
тесты на хрень")? А если мне надо пересобрать и перепрогнать один из
тестовых бинарников?
Ну, то есть, допустим, у меня будет не project и project/t, а project и
project_tests. Сиблинги. Ну, допустим, раз они сиблинги, даже можно
сделать ../Makefile. И вот мне надо пересобрать один из тестовых
бинарников после правки исходника в проекте, и прогнать его штатным
образом. То есть создав ему развесистую среду и передав несколько
штатных параметров. Общая длина командной строки - символов 200.
Сейчас у меня, с гнутым мейком, такой запуск делается отдельной целью в
мейкфайле тестов. Она умеет пересобрать _свой_ бинарь. Я нахожусь при
этом в директории с тестами (я же хочу прогнать тест после правки, и
только этот мейкфайл в курсе, как прогнать этот конкретный тест).
Разумеется, я хочу все это сделать одной командой.
В принципе, я готов на make all в собственно проекте, хотя тоже без
лишней необходимости не хотелось бы. Но на прогон всех тестов я не
готов, это минут 40. На пересборку - тоже. Мне только один. И один
его прогон (при полном прогоне этот бинарь может гоняться не единожды).
Но обязательно - корректно. Т.е. с учетом изменений в проекте.
Это как будет сделано в случае с nbmake?
Делать отдельный проект под каждый прогон очень бы не хотелось... Ну,
то есть до такой степени не хотелось бы, что если такова идеология, то
ну его нафиг.
И сразу, чтоб два раза не вставать. А как у этих замечательных скриптов
с поддержкой кросс-компиляции? На одной и той же машине с "родной",
естественно. А с сосуществованием одновременно нескольких сборок под
разные платформы (исходники общие, раздаются по NFS - интересно,
естественно, состояние до коммита, посему набор исходников один)?
Гнутому мейку мы все руками объясняли (ой, какая там кривизна...), но у
него замечательных скриптов от вендора нету.
>> То есть, задачу ты не решил ни формально, ни фактически. По разным
>> причинам, но не решил.
AC> Если ты АБСОЛЮТНО уверен в том, что ты Д'Артаньян, а остальные все
AC> пианисты, и в том, что make твою задачу решить не в состоянии,
AC> тогда нечего задавать вопросы публично. Можешь пребывать в своем
AC> неведении и дальше. Мне от этого ни холодно ни жарко.
Ну, задачу-то я могу и дать. Ту самую, которую я не могу решить
средствами make. Там не только recursive, там еще и автогенерируемые
зависимости, и зависимость от параметров сборки (только что обсудили), и
пересборка после cvs up, и чего-то еще веселенького до кучи...
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Пользователь юникса перестаёт быть пользователем юникса если после его
пользования пользованный юникс перестаёт быть юниксом. (с)
Reply to: