Цитата(ARV @ Nov 17 2009, 16:13)

что касается makefile.
мне не нравится, что его нужно править вручную, помня при этом многочисленные ключи компилятора-линкера и т.п. я понимаю, что это "свобода", что так делают "настоящие пацаны" и прочее. но тем не менее, все мы сидим не в консоли, а в GUI с окнами, юзаем редакторы с подсветкой синтаксиса и подсчетом скобок и т.п. - почему же считается хорошим тоном отказаться от возможностей управлять сборкой с аналогичным комфортом?
Хорошо вас понимаю. Комфортность работы - не последнее дело в процессе разработки. Чтобы не тратить силы на борьбу с побочными эффектами применяемых инструментов. Но вместе с тем, не могу согласиться, что руление через IDE есть удобный способ. Все эти IDE - они разные. Пересел на другую платформу и там все по-новой надо изучать. И помнить, что к чему при поднятии старых проектов (особенно, когда имел дело с ними давно). Поэтому единообразное управление на основе скриптов до сих пор является универсальным и самым мощным средством, а удобство - это во многом вопрос привычки: если постоянно возитесь со скриптами в разных проектах, то будет комфортнее поправить что-то в скрипте, нежели рыться в бесконечных табах и менюшках оболочки, когда уже все забыл, где что там лежит, т.к. последний раз сюда лазил два месяца назад (в лучшем случае).
Что касается подсветки синтаксиса и т.п. Вот вы пишете программу в редакторе и ее вид вас не пугает. Более того, вы находите естественным этот способ описания функциональности вашего целевого проекта. Так почему же не использовать этот же способ и для управления инструментарием? Т.е. тоже в редакторе и тоже с подсветкой синтаксиса и code completion и прочими вкусностями. При этом вы не отягощены привязкой к какому-то конкретному интерфейсу, совершенно свободно сами определяете, как что и где разместить. Т.е. не только функциональность собственно скрипта, но и оформление его, так чтобы было самому удобно и понятно, где что и как размещено.
Единственно, в чем соглашусь с вами, это то, что make явно не самый лучший вариант для описания функциональности сборки. Во-первых, он, главным образом, только умеет вызывать внешние инструменты. Да, там есть кое-какие встроенные средства для работы со строками, списками, файлами, но это довольно бедно и читабельность этого кода весьма никакая. А такие потребности возникают часто - что-то проверить, что-то переименовать не не просто, а по хитрому закону, где-то что-то подсунуть вместо, сгенерировать значения и подсунуть их при сборке, дополнительно обработать вывод запущенного тула и выдать уже обработанный вид и т.д. Тут приходится обращаться к внешним утилитам. Процесс сборки усложняется и специализируется, что вообще-то совсем не наша цель.
Сам много лет работал с make. Начинал с борландовского, потом через непродолжительное время перешел на более продвинутый (хотя и со своими "гусями") GNU make. Процесс освоения шел довольно болезненно. Самым тяжелым для меня были две вещи.
1. "Птичий" язык makefile - без документации под рукой частенько бывало не обойтись, дабы освежить все эти хитрые закорючки типа {:content:}lt;, $* и т.п., чем отличается $(@D) от $(<D) или от $(%D) и т.д. Сами выражения через постоянные подстановки - это надо иметь привычку, которая при работе с нормальными ЯП не требуется.
2. Необходимость в дополнительных внешних утилитах и стыковки с ними.
Года два-три назад нашел, наконец, то, что было нужно. Система сборки проектов на основе языка Python. Называется SCons. По принципам организации все похоже на make - вместо makefile используется корневой скрипт SConstruct. Но это уже скрипт на нормальном ЯП, с очень приятным синтаксисом и всем набором средств. Причем, работа со строками, файлами, обработка текста там как раз являются сильной стороной. Например, ваша задача решается там написанием фукнции, которая открывает исходный файл, генерит из него новый с обработанными местами и подсовывает компилятору этот измененный файл. Все средства как для выбора файла, его обработки, так и подсовывания, содержатся в самом инструменте. Никаких внешних дополнительных тулзов не нужно. И открыв, например, через полгода этот скрипт, все делается понятно, т.к. код сам по себе прозрачен и прост.
Сам SCons появился как развитие подобной системы на языке, кажется, Perl, которая называется Cons. Т.ч. если близок перл, а не питон, то это тоже вариант. Вроде, что-то подобное еще есть на языке Tcl (хотя у меня на Tcl аллергия

). Вообще, не хочу, чтобы мой пост воспринимался как реклама, хотелось бы только поставить акцент на том, что несмотря на большую заслуженность утилит make, их долгую службу на благо дела программизма, они не лишены системных недостатков, которые ограничивают их применимость и развитие. Поэтому имеет смысл обратить внимание на системы сборки нового поколения, основанные на скриптовых языках.
Попробовав такой инструмент, вы убедитесь, что работать с ним куда удобнее, чем GUI оболочки. GUI оболочек хороши только для быстрого старта, когда надо с ходу что-то проверить, посмотреть, быстро собрать проект, не вникая в особенности тулчейна. Далее, при серьезной работе обязательно приходится разбираться со всем этим, и тут возможности скриптов несравнимо перевешивают возможности оболочек.