Билд систему посоветуйте

luna89

Надо компилировать файлы *.coffee в файлы *.js. Билд-система должна висеть в фоне и слушать нотификации от файловой системы, перекомпилируя измененнные файлы.
Все основанное на nodejs - говно для js-макак. Make и прочие не катят, так как не могут работать в режиме демона. Из оставшегося показались крайне интересными:
1)http://gittup.org/tup/
К сожалению, с трудом запускается на убунте и с большим трудом на OSX
2)http://github.com/apenwarr/redo
Очень близко к тому что нужно. К сожалению, есть такая проблема: сначала надо сгенерить список таргет js файлов. Для этого надо взять список coffee файлов, отрезать начало пути (src папку приставить target папку, заменить расширение coffee на js. Затем, в правиле для получения js файла, надо все это проделать в обратном порядке, чтобы получить путь к сорс файлу. Выглядит это жутко тупо. Меня самого это не остановило бы, но других я вряд ли смогу убедить пользоваться этим.
Есть еще такая проблема, что многие разработчики знают только одну платформу, например джаву или js. Юникс уже может не входить в список знакомых платформ. В результате вместо того чтобы написать одну language agnostic билд систему основанную на unix конвенциях люди переизобретают какие-то дерьмовые билд системы под каждый язык.

elenangel

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

а зачем именно так?

luna89

Во-первых, это очень удобно. Сохранил файл, а у тебя уже все скомпилилось. Или сделал git checkout, и не надо отдельно make запускать. Во-вторых, так привыкли работать абсолютно все js-программисты.

zya369

while(true); do make; sleep (1); done

luna89

Это не прокатит, так как там еще на каждое сохранение юнит-тесты запускаются.
К тому же, для js-программистов make не подходит все же. Табы опять-таки. Мне redo понравился тем что там нет никакого специального синтаксиса. Redo файлы можно на чем угодно писать - это обычные скрипты.

zya369

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

luna89

Про циклы я подумаю.
Вообще, пока самое классное что я видел - tup. Абсолютно то что нужно. Работал бы он еще под OSX, вообще было бы классно. Нравятся две вещи:
1)Не надо генерить список .o по списку .c с помощью каких-то страшных макросов или выражений на баше. Как я понял, DAG строится снизу вверх, а не сверху вниз как в мейке. Я говорю примерно вот про что:
http://solovyov.net/en/2012/showkr/

SOURCE = $(patsubst app/%.coffee, %.js, $(wildcard app/*.coffee



all: $(addprefix build/, $(SOURCE) index.html)



build/%.js: app/%.coffee

    @mkdir -p $(@D)

    coffee -pc $< > $@ 

В tup как я понял это было бы примерно

: foreach app/*.coffee |> coffee -pc %f > %o |> build/%B.js

2)Tup удаляет старые js файлы

yroslavasako

А почему бы не заставить make работать в режиме демона? Берёшь gitwatch, он дёргает гит каждый раз, когда что-то меняется в папке (inotify прописываешь в git скриптах на после коммита выполнение make, и радуешься.

apl13

К тому же, для js-программистов make не подходит все же.

В двух словах: а почему?

artimon

gruntjs + grunt-contrib-coffee

luna89

gruntjs + grunt-contrib-coffee

С него начинали как раз. Он не умеет перекомпилировать только измененные файлы. Еще грунт - это один процесс, а так как это nodejs - то один поток. У нас сейчас код грантом компилится секунд 5 примерно.

YUAL

Ого. 5 секунд на компиляцию. серьёзное время.

istran

Это не прокатит, так как там еще на каждое сохранение юнит-тесты запускаются.

while true; do inotifywait -r -e modify .; make; done;

К тому же, для js-программистов make не подходит все же.

Это почему? Аргумент про табы неубедителен.

istran

Ну и КМК не стоит запускать тесты на каждой изменение. Да и вообще странно, что тесты запускает make.

luna89

while true; do inotifywait -r -e modify .; make; done;

Не прокатит. Save all в редакторе сгенерит несколько эвентов. На каждый эвент запустится make. Эти мейки станут ребилдить один и тот же файл.
В redo когда процесс начинает ребилдить файл, он лочит строчку в sqlite. За счет этого можно запускать помногу процессов redo и все будет ок.
Update: я сначала неправильно прочитал твой скрипт. Но он все равно некорректен. Если какой-то файл будет изменен в процессе работы мейка то информация об этом апдейте будет потеряна.

serega1604

Вообще если ты фронтенд пишешь, то я бы сделал модуль для веб-сервера, который при обращении к '*.js' будет сравнивать таймстемп соответствующего .coffee и вызывать компилятор. Если при этом еще уметь компилятор держать в памяти, то будет работать отлично.

yroslavasako

посмотри всё-таки gitwatch, там все этим моменты рассмотрены

capxaH

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

luna89

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

Спасибо за совет, но у всех этих систем на nodejs одна проблема - колхозный дизайн. Билд система должна позволять описать зависимости между файлами, а все сложные вещи сделать автоматически. Например, вычислить, какие файлы надо перекомпилировать, а какие нет, или распараллелить билд. В документации к этому гульпу написано

Incremental Builds
We recommend these plugins:
gulp-changed
gulp-cached
gulp-newer

То есть самая базовая фича билд системы - сравнение таймстемпов сорс и таргет файлов - не реализована из коробки а реализуется плагинами(!). Вот тут вообще предлагается внутри конфиг файла педалить асинхронное программирование с промисами.