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

[Björn-Egil Dahlberg]

2013/1/25 ノートン ジョーセフ ウェイ ン <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.

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.

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. =)

Build the rest of OTP with rebar, pulled down via git or some other means.

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'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.

but I digress, to answer your question. I don't think there is a technical
problem, but perhaps an administration problem. I would like to see rebar
thrive outside OTP.

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

// Björn-Egil




>
> Just curious.
>
> thanks,
>
> Joe N.
>
>
> p.s. I have been toying with this idea on GitHub.
>
> https://github.com/organizations/otphub
>
> I haven't spent any significant time on this exercise … just out of
> curiosity.
>
>
>
>
> On Jan 25, 2013, at 11:05 , Björn-Egil Dahlberg <
> wallentin.dahlberg@REDACTED> wrote:
>
> 2013/1/25 Scott Lystig Fritchie <fritchie@REDACTED>
>
>
>> So, almost 1.3 seconds to start up and stop.  Some of that time is
>> probably related to shutting down.  The rest is probably startup time.
>> Some fraction of that is probably the same overhead that starting "erlc"
>> from scratch each time, plus some overhead that "erlc" has that "erl"
>> doesn't.  Reduce that sum of time, and you'll save a lot of time in your
>> Makefile recipes.  Plus, that reduction would likely make "escript"
>> startup times lower, which would also please a lot of the Erlang world
>> also?
>>
>
> Though we now have parallel code loading, we don't have parallel code
> fetching during boot. I think most of it is dynamic on-demand fetching in a
> sequential process anyways.
>
> I think something like spec:ing what modules should be loaded in default
> boot or app-file is the way to go. Start app -> batch parallel modules
> loading. We want something reasonable thought through. =)
>
>
>
>> P.S. Keeping mouth shut since rebar's automatic parallellization doesn't
>> seem to interest everyone else in the thread.... :-)
>>
>
> rebar is awesome!
>
> I wonder why some people seem to shy away from it?
>
> I don't know if it is feasible to use rebar to build erlang applications
> within otp. I don't think so. It would be nice to have something like that
> and Emake needs a lot more attention if it would have the same role. We
> don't want to make yet another make-tool. it's just silly, we have rebar.
>
> I think if we ever manage to move out applications from otp, that we still
> maintain, those should use rebar to build them. (I'm a big proponent of
> splitting down the monolithic otp-repo, let's say its not really
> prioritized). Within the otp-repo we will use make + erlc for the
> foreseeable future.
>
> On another note,
> if rebar is the build-tool, what application is the concrete? A repository
> search and deploy engine?
>
> // Björn-Egil
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130125/26711801/attachment.htm>