[erlang-questions] how do you build your releases with/without rebar?
Thu Apr 10 17:46:38 CEST 2014
> In general, none of the Erlang build tool really make it easy to
> distinguish between apps I use and never touch (say, cowboy, jsx,
> erlsom, etc.) and apps I use and will keep on modifying all the time
> (two or three apps I own and may be developing together in a system).
As a know-little relative noobie just beginning to struggle with these issues, I can only say at this point that my head hurts.
Oh how I wish that an Erlang guru would write and publish the definitive tutorial on how to organize and build a large Erlang project in simple, easy-to-understand language.
All the best,
From: "Fred Hebert" <>
Sent: Thursday, April 10, 2014 8:02am
To: "Loïc Hoguin" <>
Cc: "" <>
Subject: Re: [erlang-questions] how do you build your releases with/without rebar?
On 04/10, Loïc Hoguin wrote:
> It does not support the terrible apps/* layout directly, but it's easily
> done using a top-level Makefile like the one that was posted in that other
> thread earlier today: https://gist.github.com/RJ/6977165
There's nothing terrible for that layout. It's in fact the one used by
OTP itself (replace 'apps' by 'lib' as a name).
It's, in my opinion, the most logical structure to build releases where
you have many applications that you manage yourself. How weird would OTP
be as a release if it had that structure?
It just doesn't always make sense to have one top-level application be
set apart in a system. The moment you own two specific apps that may run
at the top level, whatever they might be, the apps/* layout starts
making sense, especially when the project is still too small to warrant
having a separate repository just to build releases in (the way Basho
does it for Riak, more or less).
The real pain with it at this point is in the poor support from tools. I
gave the example of running the CT suites with rebar of all apps in
apps/ yesterday in IRC. This requires calling 'rebar ct -r
skip_deps=true' to make the command recursive, but ignoring deps when
running it. It's less than optimal, but at least works. Figuring it out
is non-trivial, however!
In general, none of the Erlang build tool really make it easy to
distinguish between apps I use and never touch (say, cowboy, jsx,
erlsom, etc.) and apps I use and will keep on modifying all the time
(two or three apps I own and may be developing together in a system).
Tools (read: rebar, erlang.mk) more or less just assume you're gonna
build everything from a single top-level OTP app, every time, whether
it's a release or not. Older tools like Sinan didn't, but they lost to
convenience over time.
erlang-questions mailing list
More information about the erlang-questions