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: [EMAIL PROTECTED] Пользователь юникса перестаёт быть пользователем юникса если после его пользования пользованный юникс перестаёт быть юниксом. (с) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]