erlang build tool

1. Зависимости только из *.app получаются, или и из *.beam?

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

зависимости конфигурятся в сборке. Из апп они не получаются по двум причинам: они могут быть опциональными и потому в app будут отсутствовать, и потому что там нет версии. Если бы она там была все было бы проще.

А можно в нескольких словах: какие недостатки rebar преодолены в EBT

ёбт!

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

В ребаре компиляци например eunit идет отдельно, и потому напимер не делает app файл, и потому нельзя в тесте запустить аппликуху. Тут это нормальная компиляция - что скопиллил то и тестируешь.

Зависимости ребара - по исходникам. Порождает хреновую практу линканья до последнего мастера. В результате открываешь проект чере 3 месяца - а он уже тупо не собирается потому что зависимость поменялась. Здесь зависимости бинарные с поддержкой версий. То есть открывай хоть через 100 лет - если в репах есть соответствующие ez файлы - сборка воспроизводима - как во всяких мавенах.

В ebt можно собрать прямо до эрланговоского OTP release вместе с запускалкой под linux которая совместима с SysV init.

Расширять ребар - это врагу не пожелаешь. Все что там есть это командный интерфейс который можно инвойкнуть. Здесь (см туториал) это делается в пару строчек кода и интегрируется в любую фазу сборки свои тулы. Например позавчера я за 10 минут написал подержку графвиза.

Можно пересобрать если надо процесс сборки полностью переопределив дерево зависимостей.

Можно существующие таргеты параметризовать по другому вставля в другие места сборки.

Есть поддержка множества профилей - то есть можно сделать девелопмент профиль, профиль сборки на CI, профиль сборки на «текущая проблема». Можно вплоть до определения нескольких деревьев конфигов в многомодульной сборке.

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

В дополнение - пруф оф концепт собственно здесь:

https://github.com/vladimirk/ebt-build-service/tree/master/projects

Это сборочные скрипты для всякого эрлангового опенсорса. Чтобы собрать ковбой например весь скрипт сборки:

{define, version, {shell, "echo -n `git describe --tags --abbrev=0`"}}.
{profiles, [
    {default, [
        {prepare, [clean, depends]}
    ]}
]}.

{depends, [
    {dir, "./lib"},
    {repositories, [
        {"http://erlang-build-tool.googlecode.com/files", [
            {ranch, "0.6.2"}
        ]}
    ]}
]}.

{libraries , ["./lib"]}.

Он гораздо проще сборочных скриптов самого ковбоя.

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

Годнота!

{ranch, «0.6.2»}

Может всё-таки branch?

Отлично, обязательно посмотрю!

ranch - это либа - ранчо на которой гарцует веб сервер ковбой:)

Воу.

Отлично!

Не хочу показаться занудой, но в readme.md на гитхабе нашёл следующие грамматические ошибки:

NOTICE: Erlang version requireid is Erlang R15.
contains compiled version of our OTP aaplication
You will see in output that eunit found your tests and perfoprmed it
The source of the defition could be shell command invocation
Default dependecy configuration is defined

Можно найти поиском.

tnx

Спасибо!