Лично я убежден на 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. Мини утилитка на С, которая писалась на коленке, делает это менее чем за секунду. Все мои попытки на Питоне работали минуты. Получается, что идея опять не чиста, так как нужны опять сопровождающие утилиты, и уже не ясно, зачем что-то менять как оно есть сейчас.
В целом, мои изыскания в области идеальной утилиты организации сборки пока не увенчались успехом. Но поиск продолжается.
Посты по теме:
Сообщения
Я использую SCons и очень-очень его люблю. Ваша проблема со скоростью работы конверторов может быть успешна решена при помощи сишного расширения к Питону. Так делают всегда, когда нужна скорость.
ОтветитьУдалитьСишный код у вас уже есть, сделать обвертку для подключения -- дело пары часов. Саму обвертку также можно компилировать самим SCons. Так что зря вы так сразу рубите с плеча.
Не, решения еще нет, так что может и на SCons остановимся. Для своих собственных проектов я давно на SCons'е, так как можно сделать все без всяких велосипедов, но мои собственные проекты далеки по объему и организационной сложности. И когда вовлекаются много людей в работу, то аргументы должны быть немного убедительнее, если ты заставляешь людей что-то менять, пусть даже в лучшую сторону, но при этом им надо что-то делать по старинке со всякими велосипедами.
ОтветитьУдалитьПодскажите пожалуйста, как соотносятся продукты SCons и Hudson? Одно ли это и то же по замыслу, но от разных производителей, или у них разные назначения, а может быть, они пересекаются частично?
ОтветитьУдалитьЭто, конечно, разные вещи.
ОтветитьУдалитьSCons - это средство автоматизации процесса сборки (типа make). То есть это эдакий проджект менеджер. Запускаете SCons, и он производит компиляцию/сборку проекта по вашему сценарию.
Hudson - это штука для автоматизирования многих процессов. С помощью консоли на мастер-машине можно управлять многими подчиненными машинами. Самое простое и очевидное применение - это плановый запуск сборки проекта(ов). Например, раз в день, или каждый раз, когда кто-то соммитит что-то в систему контроля версий, Hudson дает команду подчиненым машинам синхронизировать исходники, собрать проект и прогнать тесты. Как вариант, Hudson может запускать SCons на удаленной машине для сборки.
Все ясно, спасибо!
ОтветитьУдалить