Новый формат описания проектов - BuilDj

Ant - это слишком низкоуровневая утилита, чтобы собирать большой проект с множеством опций прийдётся приложить намного больше усилий чем, скажем, используя Maven.

Я собираю одинм скриптом три десятка разных проектов.

А так да - на Ant можно сделать всё, как и любую программу можно написать на ассемблере.

На ант можно написать те самые высокоуровневые абстракции. Например у меня скрипт сборки jar-модуля проекта выглядит вот так:

> cat core.module

framework.package.name = xxx-hotfolder
framework.manifest.title = HotFodler Framework
framework.manifest.vendor = XXX Ltd
#framework.manifest.main.class =
framework.source.version = 1.5
framework.libraries = lib/*.jar, core/lib/*.jar
#framework.resources = framework/src/**/*.tld
framework.sources = core/src
framework.use.scala = true
#framework.meta.resources = 
#framework.package.include = 
#framework.antlr.grammars = 
#framework.sign.keystore = 
#framework.sign.cert.alias = 
#framework.sign.storepass = 
#framework.wscompile.configs = 
#framework.wsimport.services = 
#framework.wsgen.services = 

таких модулей наверное сотни полторы по всем проектам, и в них все - JNI, вебсервисы, всдли,жаксбы, парсергенераторы antlr и javacc

Когда доберусь со своими минимизаторскими позывами и автодискавери позщівами - даже 9/10 этого конфига исчезнет.

А вот так собирается релиз с инсталяшкой, сплешскринами, запускными файлами и прочей интеграцией в разные эпловские менюхи:

> cat admail.release

framework.package.name = admail
framework.resources = desktop/conf/**/*, desktop/data/wficons/**/*, desktop-admail/data/**/*
framework.libraries = daemon/lib/*.jar, workflow/lib/*.jar, servicecore/lib/*.jar, desktop/lib/*.jar, \
  ftp/lib/*.jar, filesystem/lib/*.jar, data/lib/*.jar, http/lib/*.jar, unihf/lib/*.jar, \
  dist/xxx-markii-servicecore.jar,\
  dist/xxx-markii-data.jar,\
  dist/xxx-markii-desktop.jar,\
  dist/xxx-markii-daemon.jar,\
  dist/xxx-markii-bcerrors.jar,\
  dist/xxx-markii-workflow.jar,\
  dist/xxx-markii-workflow-filesystem.jar,\
  dist/xxx-markii-workflow-xml.jar,\
  dist/xxx-markii-workflow-ftp.jar,\
  dist/xxx-markii-workflow-http.jar,\
  dist/xxx-markii-workflow-unihf.jar,\
  dist/xxx-markii-workflow.jar

#framework.libraries.endorsed = nodeclient/lib/endorsed/*

installer = yes
installer.base = install
installer.app.name = Admail

splash = desktop/etc/splash.png
splash.target = xxx-bootstrap.jar

при чем каждый из этих сборочных скриптов _нихрена_ не знает про проекты которые собирает - они универсальны и реюзаются в десятках проектов.

Ант позволяет написать автосборочные универсальные скрипты.

А мавен со всеми его «высокоуровневыми фишками» для меня слишком... многословен. Там одну зависимость описать занимает больше чем у меня весь модуль.

> почему первые два параметра записаны просто в кавычках, а вторые два еще и в квадратных скобках.

А непонятно, что это массивы?

> А вот так собирается релиз с инсталяшкой, сплешскринами, запускными файлами и прочей интеграцией в разные эпловские менюхи:

Ха. Ты с тем же успехом мог написать:

build.sh

в дополнение -

cat .build/build-module.xml | grep -v -e «^$» | wc -l

161

для первого конфига который сделает все - сгенерирует жнай перепакует и подпишет, сгенерирует по граматикам парсеры, сгенерирует вебсервис клиента или сервер используя джаксб или старый всимпорт и тд.

для второго конфига:

cat .build/build-release.xml | grep -v -e «^$» | wc -l

81

Если ваши скрипты на анте большие - вы неправильно их пишете.

Ха. Ты с тем же успехом мог написать:
build.sh

вон там выше количество строчек. Для оценки подхода вот кусок:

      <target name="xjc-generate">                                                                                         
                <taskdef name="xjc" classpathref="project.class.path" classname="com.sun.tools.xjc.XJC2Task" />              
                <dirname property="destination" file="${project.home}/${schema}.xsd"/>                                       
                <xjc schema="${project.home}/${schema}.xsd" binding="${project.home}/${schema}.xjb" destdir="${destination}">
                        <classpath refid="project.class.path"/>                                                              
                </xjc>                                                                                                       
        </target>                                                                                                            
        <target name="xjc" if="framework.xjc.schemas">                                                                       
                <foreach list="${framework.xjc.schemas}" param="schema" target="xjc-generate"/>                              
        </target>                                                                                                            
        <target name="pre-compile" depends="clean, compile-antlr, compile-javacc, xjc, wsgen, wscompile, wsimport"/>         

        <target name="compile-scala" if="framework.use.scala">
                <taskdef resource="scala/tools/ant/antlib.xml" classpathref="project.class.path"/>
                <scalac destdir="${project.home}/build/${framework.package.name}" encoding="UTF-8" force="always"
                        classpathref="project.class.path" srcdir="${framework.sources}"/>                        
        </target>                                                                                                
        <target name="resolve-local-compiler" if="framework.jdk.home">                                           
                <property name="_jdk.home" value="${framework.jdk.home}"/>                                       
        </target>                                                                                                
        <target name="resolve-global-compiler" unless="framework.jdk.home">                                      
                <property name="_jdk.home" value="${jdk.home}"/>                                                 
        </target>                                                                                                
        <target name="compile-java" depends="resolve-local-compiler, resolve-global-compiler">                   
                <echo level="info" message="Building with jdk ${_jdk.home}"/>                                    
                <javac executable="${_jdk.home}/bin/javac" classpathref="project.class.path"                     
                                         srcdir="${project.home}/${framework.sources}" destdir="${project.home}/build/${framework.package.name}"
                                         debug="true" fork="true" encoding="UTF-8" target="1.5">
                        <compilerarg line="-Xlint:unchecked -Xlint:deprecation"/>
                </javac>
        </target>

талганнер - ты еще учти что этот «build.sh» - это все что мне надо написать для того чтобы собрался совершенно новый проект. Сборочные скрипты залинкованы экстернал ресурсом в svn, и одинаковые для всех проектов.

чево мне в анте не хватает - так это номальных вычислялок экспрешшенов (типа если есть то и то и продевайнено то - правило применяется) как в nant хотябы. Хотя может руки дойдут - есть план переписать сборку на основе clojure c биндингом в антовские таски.

и дико мпрачно раздражает readonly пропертей - из-за этого вот то бредовое шаманство в вычислении какой жабой собирать в примере.

> еще учти что этот «build.sh» - это все что мне надо написать для того чтобы собрался совершенно новый проект

Это значит одну простую вещь - Ant умеет использовать библиотеки :)

> а ктонить пробовал SCons ...

Ну, я пробовал. Несмотря на моё, в общем, тёплое отношение к питону, могу сказать, что _такой_ сборочная система быть не должна. Уж лучше через distutils инсталляться (да, я в курсе про ограничения и неполноту последних).

> Конфигурировать cmake-файлы с помощью внешнего конфигуратора - это уж как-то через край

Нет. Хочется полноценной поддержки проектов на CMake в «IDE».

P.S. Активно пользуюсь cmake -G «Eclipse CDT4 - Unix Makefiles». Но это не вполне тот способ, которым удобно пользоваться. Например, средствами IDE практически невозможно исключить из сборки какой-либо файл.

> Расскажи теперь, почему первые два параметра записаны просто в кавычках, а вторые два еще и в квадратных скобках.

Потому что они имеют разную семантику? Вторые - списки.

>Это значит одну простую вещь - Ant умеет использовать библиотеки :)

Ты не поверишь - ant+ant-contrib(ради форича) - достаточно - больше ничем не пользуюсь. Я к стати пребываю в первобытном ужасе когда смотрю на эти дикие антовские скрипты которые народ пишет. И не понимаю зачем они пишут их _так плохо_.

Затем же, зачем они писали ужас в Makefile.am и configure.ac. Немногие способны почувствовать красоту и мощь языков макроподстановки а-ля M4.

Я юзаю SCons в довольно большом проекте на с++, с кучей модулей, которые линкуются с чем попало. В проекте есть гуй на Qt (moc и всё такое), пропатченные левые либы, собираемые вообще собственными сборщиками на perl и cmake, куча плагинов и консольных утилит с разными зависимостями. Сборка архивов и инсталяторов там же.

Не могу сказать что всё идеально, но таки гибко.

А раньше у меня был скриптик о 20 строчках на gnu make, который собирал (с минимальными изменениями), разные, но всё таки очень похожие по структуре проекты. Так что хвалится этим можно тока до поры до времени.

Я для конфигов тоже YAML предпочитаю, но не вижу катастрофической разницы, чесслово.

...и в 18000 раз медленнее.

>Почему? Действительно интересно. Вроде как в примерах все красиво и очень читабельно. XML мне читать гараздо менее приятно.

Это пока примеры коротенькие, а как только конфигурационники начнут разбухать, так сразу возрастает вероятность внесения ошибки (выше, чем у XML). К тому же JSON, это по сути XML для ECMAScript, но особый XML - с синтаксисом ECMAScript. Документировать JSON несколько сложнее, чем XML. Как альтернативный вариант описания JSON вполне сгодится, но во главу угла его ставить - тот еще изврат. Зная гномеров, серьезно опасаюсь, что после введения этой «фичи» треть гнома будет в нее «запаковано». А потом «вдруг» окажется, что с введением фишки немного «поторопились» и практика показала, что JSON «не такой универсальный, как божились создатели» и т.п.

> Они же (и мэйвен, и ант) громоздкие до степени отвращения.

apache-ant-1.7.1-bin.zip ~ 11,1МБ
apache-maven-2.2.1-bin.tar.gz ~ 2,8МБ

Всё-таки Maven больше подходит для больших проектов, так как в отличие от Ant поддерживает полное управление жизненным циклом приложения и его зависимостей, а не только сборку и тестирование.

> ...и в 18000 раз медленнее.

К.О. напоминает, что время сборки заивисит только от скорости компиляторов.

И не понимаю зачем они пишут их _так плохо_.

Что поделаешь — Ant подталкивает писать инструкции практически в императивном стиле, а не в декларативном (который принят в Maven). Ничего что и там и там «декларативный» XML.

Замени Ant-скрипт на Bash и, по-сути, ничего не изменится, кроме как сборка будет возможна только там, где есть Bash.

>Замени Ant-скрипт на Bash и, по-сути, ничего не изменится, кроме как сборка будет возможна только там, где есть Bash.

Внезапно http://win-bash.sourceforge.net/! Маковский тоже есть.

>Маковский тоже есть.

Ты не поверишь - он там из каробки ;)

>К.О. напоминает, что время сборки заивисит только от скорости компиляторов

авотнет. Если собирается проект на яве, то заметную часть времени сборки занимает а)«разогрев» явы в начале б)перепаковка jar-ов в конце. Сама компиляция же идет в лет, со скоростью сотен файлов в минуту

> Ты не поверишь - он там из каробки ;)

Так я это в виду и имел, модераторы не дадут соврать.

>Расскажи теперь, почему первые два параметра записаны просто в кавычках, а вторые два еще и в квадратных скобках.

ну логично предположить, что без скобок параметры единичные, а в квадратных скобках массивы, то есть параметры со множеством значений.

>Документировать JSON несколько сложнее, чем XML.

и поэтому вся документация в зумеле обычно сделана банальными комментариями.

>>К.О. напоминает, что время сборки заивисит только от скорости компиляторов

авотнет. Если собирается проект на яве, то заметную часть времени сборки занимает а)«разогрев» явы в начале б)перепаковка jar-ов в конце

К.О. вынужден напомнить, что компилятор явы написан на яве и исполняется на ява-машине, и ее разогрев является частью работы компилятора. Перепаковка jar'ов - это тоже стадия сборки проекта (линковка, если угодно), в котору система _управления_ сборкой никакого вклада не вносит.

> К.О. напоминает, что время сборки заивисит только от скорости компиляторов.

Пробовал я как-то перевести проекты с make на SCons. Так вот сборка scons-ом выполнялась процентов на 20 дольше.

> Пробовал я как-то перевести проекты с make на SCons. Так вот сборка scons-ом выполнялась процентов на 20 дольше.

Говорят, он md5 исходников вычисляет :)

> Я не спец, но говорят что ментейнеры хватаются за пистолет от Maven.

За пистолет хватаются не только мейнтейнеры, а еще и те кто этот maven пытается использовать ;)

> apache-maven-2.2.1-bin.tar.gz ~ 2,8МБ

Считай это только запускалкой, которая ничего не умеет. Оно первым делом полезит в инет качать своё барахло

>К.О. напоминает, что время сборки заивисит только от скорости компиляторов

И механизма их запуска. Ант в первую очередь изобретали потому что мейк с запусолм javac на каждый файл работал феерически медленно (особенно в те времена) из-за скорости стартапа jvm, по сравнению например с «ручным» запуском.

Нет.

> Нет.

Да.

Нет. Он не себя вытягивает за волосы, а зависимости проекта, который ведёт.

Сконс отличная штука во время разработки он действительно пересобирает только то что реально нужно пересобрать. Про очистку от результатов сборки забываешь напроч.

Синтаксис очень красивый, понятный и офигенно гибкий. Кстати там именно декларативное описане проекта, так как билдеры только прописывают зависимости, а не выполняют функции.

Главные недостатки, из за которых я уже несколько раз подумывал о переводе своих проектов на cmake: 1 Невозможно написать переиспользуемые расширения. (Новые Tools либо включаешь в свой проект напрямую, либо пытаешься пропихнуть в апстрим). Это они вроде как хотят подправить к следующему релизу определив системные и пользовательски директории для сторонних расширений. По крайней мере в списке рассылки было обсуждение. 2 Поиск зависимостей и установка сливают по полной.

> Не могу сказать что всё идеально, но таки гибко.

Нет, не в этом дело. Ясен пень, что на «настоящем питоне» можно хоть на барабанах сыграть в процессе сборки проекта. Но вот как это *оформляется* в случае SCons, мне решительно не нравится.

> apache-ant-1.7.1-bin.zip ~ 11,1МБ

apache-maven-2.2.1-bin.tar.gz ~ 2,8МБ

Нет, про размеры архивов - это, в общем, мне по барабану, сколько оно весит, при терабайтных-то винтах глупо сильно заморачиваться тем, сколько рабочие инструменты на диске отъедают. А вот через что приходится продираться _глазами_ в попытке понять, что же за проблемы со сборкой возникли в _чужом_ для тебя проекте - тут-то и начинаешь (я начинаю) ощущать все тринадцать метров мутной воды у себя над головой...

Ну и да, мозгом я понимаю, что гибкость, что ынтырпрайз, что кантиньюэс ынтыгрэйшн и прочая-прочая... Но удовольствия от использования такого ынтырпрайза не возникает.

> К.О. напоминает, что время сборки заивисит только от скорости компиляторов.

Нет. Пример с причинами появления Анта тут уже приводили. Кроме этого, невооружённым глазом видна разница в скорости пересборки с нуля проекта на autotools c аналогичным по весу и сборочным задачам проекте на том же CMake. Разница, конечно, в основном на этапе «configure», но и на нём компилятор вызывается сравнимое количество раз.

> Внезапно http://win-bash.sourceforge.net/! Маковский тоже есть.

Что Вы! Что Вы! Как можно сравнивать /эту переносимость/ с Настоящей Платформонезависимостью (tm), которую дарует своим пользователям Джава!

А вот через что приходится продираться _глазами_ в попытке понять, что же за проблемы со сборкой возникли в _чужом_ для тебя проекте - тут-то и начинаешь (я начинаю) ощущать все тринадцать метров мутной воды у себя над головой...

Maven создавался, чтобы проводить повторяемую сборку. То есть, если и возникнут какие-то проблемы, то явно не в скриптах сборки.

> На питоне я собирался (собираюсь?) реализовать только саму систему сборки

bitbake?

Это опционально, может и вермя изменения, или вычислять md5 только если время изменилось.

На мой пристрастный взгляд, у него слишком размытая зона ответственности, чтобы он делал свою задачу хорошо.

> Я собираю одинм скриптом три десятка разных проектов.

при чем каждый из этих сборочных скриптов _нихрена_ не знает про проекты которые собирает - они универсальны и реюзаются в десятках проектов.

респект

> Хочется полноценной поддержки проектов на CMake в «IDE».

KDevelop4 умеет использовать CMakeLists.txt в качестве проектноых файлов

> Пробовал я как-то перевести проекты с make на SCons. Так вот сборка scons-ом выполнялась процентов на 20 дольше.

Многовато как-то... Но в любом случае, это потому что SCons сам вызывает компиляторы/линкеры/etc. В случае с CMake (с переписывания на питоне которого и начался этот разговор), утилита сначала генерирует Makefile'ы, а потом запускается обычный make.

>> Я не спец, но говорят что ментейнеры хватаются за пистолет от Maven.

За пистолет хватаются не только мейнтейнеры, а еще и те кто этот maven пытается использовать ;)

Перед использованием стоит таки прочитать мануал. Думаю за пистолет хватаются те, кто использует Maven как Ant.

>> На питоне я собирался (собираюсь?) реализовать только саму систему сборки

bitbake?

хм... спсибо за наводку, посмотрю.