[erlang-questions] erlc speed (or lack thereof), Make and emake

[Loïc Hoguin]

On 01/25/2013 03:49 AM, Björn-Egil Dahlberg wrote:
>
>
> 2013/1/25 ノートン ジョーセフ ウェイ ン <norton@REDACTED
> <mailto:norton@REDACTED>>
>
>
>     Bjorn -
>
>     Why do you think it isn't feasible to use rebar to build erlang
>     applications within OTP?
>
>
>
> Well, rebar would be a key-component to build otp. That means that rebar
> probably have to be included in the repo as an application.
> Not impossible, but I don't know if it would be ideal.

It'd need a lot of work. I love rebar for the simple things, but it's a 
pain if you need to do hard things. I'm also not sure you'd gain much 
doing this, the only bad thing about compiling OTP right now is that 
there's too many applications.

> What I would like, and I don't know if anybody shares this thought:
>
> OTP split down to just a core, namely runtime system, kernel, stdlib,
> compiler, sasl perhaps a few other applications.

Definitely yes.

> External dependency to rebar. Perhaps rebar could be included in that
> core. From a technical standpoint, there is ofc no problem. But it would
> be nice to solve it in another manner.
>
> I don't really know if this is true or not, but I get the feeling when I
> use rebar that I loose some strictness and it adds some magic. A lack of
> sense of control. Just the paranoia speaking perhaps. =)

It adds a lot of magic, makes guesses as to what you want, and gets it 
right most of the time. Not as magic with more complex applications.

> Applications are nowadays normally oriented in separate git
> repositories. Seems natural to use this scheme for OTP applications as
> well.
> It has some additional advantages:
> * Promotes modularity.
> * Can have separate release cycles.
> * Developers can choose different versions for there system, not merely
> the system version R16*, R15*, R14*, etc ..
>
> I can see many advantages.

I agree with these points. Core applications should definitely keep the 
Rxx version system, but some would perhaps benefit more from being 
outside (thinking of common_test particularly). I'm also not sure what 
diameter and others are doing there.

> I'm pretty sure there are disadvantages too. Cross application updates
> that otherwise needs strict version-control can be done with one commit
> in a single repo. Thats pretty neat.

The good thing though is that if nobody cares about one such application 
you can quickly notice it and drop it or lower the amount of support you 
give to it.

> We won't go into this any further right now though.

One step at a time.

-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu