Лично я убежден на 100%, что сборка более менее серьезного по размерам проекта/продукта должна производиться в командной строке, то есть никаких GUI-сред, в которые надо заходить, нажимать кнопки, смотреть в окна результатов и т.д. Все это здорово на этапе собственно написания кода, тестирования и отладки. Но когда код переходит в стадию “почти закончен”, все должно заканчиваться полностью авторизированной сборкой без вариантов “тут надо кликнуть, тут надо ввести путь, тут надо сделать clean-up и refresh, а то все съедет” и т.д. Прелесть командной строки в том, что вне зависимости с какого ты сегодня будуна, и что твоя голова с утра проходит в дверь только боком, ты набираешь cd /my/super/project и затем make. После этого ты откидываешься на стул в мыслях о пивасике, а проект тем временем собирается и тестируется. В идеале, конечно, вместо компиляции, ты должен просто скачать свежую автоматизированную ночную сборку, которая уже там, оттестирована и готова к употреблению.
Ладно, это была всем очевидная лирика.
Наш софт представляет собой монструозный симбиоз из С, С++, Java, BASIC (это наш собственный внутренний СУБД-ориентированный язык), Python’а и UNIX-скриптов. Система же сборки основана на GNU Make и по сути является огромным многоуровневым Makefile’ом. Необходимая при сборке логика, которую нельзя реализовать напрямую в GNU Make дополняется UNIX-скриптами и мини утилитками на C, которые компилируются прямо перед запуском. Java части используют Ant. Плагин Ivy используется для подкачки из репозитория двоичных модулей. Лично я против каких-либо двоичных файлов в проекте, и считаю, что в разы удобнее все компилировать из текстового представления (пусть это и дольше по времени), так как текстовики можно сравнивать, в них можно искать и т.д. Конечно, реальная жизнь сложнее, и иногда приходится использовать заранее собранные бинарники (например, OpenSSL, ICU, тучу сторонних jar’ов для Java и т.д.).
Итак, ясно, такая сборка со временем деградирует, становится сложнее, запутаннее, в ней сложно искать ошибки, а тем более узкие места.
Я пытался все перевести на Ant – возможностей много, но все крайне Ява-центричное, расширения надо тоже писать на ней же. Если мы все писали бы на Java, но у нас не тот случай.
Пробовал CMake. Очень неплохо, но обнаружились сложности скрещения с нашим собственным компилятором Бейсика.
Пробовал SCons. Пожалуй, это самая прикольная система. Недаром ее используют в Гугле для реально нетривиальных проектов типа Chrome и Native Client и т.д. По сути Makefile – это программа на Питоне, то есть ограничения на особую логику сборки (запуск тестов, фильтров, сборка документации, публикация результатов на FTP и т.д.) просто отсутствуют. Нужное просто пишется на полноценном языке программирования Питон. Удалось мне даже собрать нормально Питон для AIX и HPUX (с Windows, Linux, Solaris проблем нет вообще). Но и тут получилась ложна гов… дегтя. У меня есть необходимость конвертировать тысячи отчетов по тестам в формат jUnit. Мини утилитка на С, которая писалась на коленке, делает это менее чем за секунду. Все мои попытки на Питоне работали минуты. Получается, что идея опять не чиста, так как нужны опять сопровождающие утилиты, и уже не ясно, зачем что-то менять как оно есть сейчас.
В целом, мои изыскания в области идеальной утилиты организации сборки пока не увенчались успехом. Но поиск продолжается.
Другие посты по теме: