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

[Björn-Egil Dahlberg]

2013/1/25 Björn-Egil Dahlberg <wallentin.dahlberg@REDACTED>

>
>
> 2013/1/25 ノートン ジョーセフ ウェイ ン <norton@REDACTED>
>
>>
>> Bjorn -
>>
>> Why do you think it isn't feasible to use rebar to build erlang
>> applications within OTP?
>>
>
>
Let me just preface everything below by saying that: I speak for myself and
not for OTP as a whole when I say this. Some may agree with some might not.
Anyways, these are my views.


>
> 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/220a45da/attachment.htm>