<br><br><div class="gmail_quote">2013/1/25 ノートン ジョーセフ ウェイ ン <span dir="ltr"><<a href="mailto:norton@lovely.email.ne.jp" target="_blank">norton@lovely.email.ne.jp</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><br></div><div>Bjorn -</div><div><br></div><div>Why do you think it isn't feasible to use rebar to build erlang applications within OTP?  </div></div></blockquote><div><br></div>
<div><br></div><div>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.</div><div>Not impossible, but I don't know if it would be ideal.</div>
<div><br></div><div>What I would like, and I don't know if anybody shares this thought:</div><div><br></div><div>OTP split down to just a core, namely runtime system, kernel, stdlib, compiler, sasl perhaps a few other applications.</div>
<div><br></div><div>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.</div><div><br></div>
<div>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. =)</div><div>
<br></div><div>Build the rest of OTP with rebar, pulled down via git or some other means. </div><div><br></div><div>Applications are nowadays normally oriented in separate git repositories. Seems natural to use this scheme for OTP applications as well. </div>
<div>It has some additional advantages:</div><div>* Promotes modularity. </div><div>* Can have separate release cycles.</div><div>* Developers can choose different versions for there system, not merely the system version R16*, R15*, R14*, etc ..</div>
<div><br></div><div>I can see many advantages.</div><div><br></div><div>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.</div>
<div><br></div><div>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. </div><div><br></div><div>We won't go into this any further right now though.</div>
<div><br></div><div>// Björn-Egil</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>
<br></div><div>Just curious.</div><div><br></div><div>thanks,</div><div><br></div><div>Joe N.</div><div><br></div><div><br></div><div>p.s. I have been toying with this idea on GitHub.</div><div><br></div><div><div><a href="https://github.com/organizations/otphub" target="_blank">https://github.com/organizations/otphub</a></div>
<div><br></div><div>I haven't spent any significant time on this exercise … just out of curiosity.</div><div><br></div><div><br></div></div><div><br></div><div><br></div><div><div><div class="h5"><div>On Jan 25, 2013, at 11:05 , Björn-Egil Dahlberg <<a href="mailto:wallentin.dahlberg@gmail.com" target="_blank">wallentin.dahlberg@gmail.com</a>> wrote:</div>
<br></div></div><blockquote type="cite"><div><div class="h5">2013/1/25 Scott Lystig Fritchie <span dir="ltr"><<a href="mailto:fritchie@snookles.com" target="_blank">fritchie@snookles.com</a>></span><br><div class="gmail_quote">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, almost 1.3 seconds to start up and stop.  Some of that time is<br>
probably related to shutting down.  The rest is probably startup time.<br>
Some fraction of that is probably the same overhead that starting "erlc"<br>
from scratch each time, plus some overhead that "erlc" has that "erl"<br>
doesn't.  Reduce that sum of time, and you'll save a lot of time in your<br>
Makefile recipes.  Plus, that reduction would likely make "escript"<br>
startup times lower, which would also please a lot of the Erlang world<br>
also?<br></blockquote><div><br></div><div>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.</div>

<div><br></div><div>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. =)</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
P.S. Keeping mouth shut since rebar's automatic parallellization doesn't<br>
seem to interest everyone else in the thread.... :-)<br></blockquote><div><br></div><div>rebar is awesome!</div><div><br></div><div>I wonder why some people seem to shy away from it? </div><div><br></div><div>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.</div>

<div><br></div><div>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. </div>

<div><br></div><div>On another note,</div><div>if rebar is the build-tool, what application is the concrete? A repository search and deploy engine?</div><div><br></div><div>// Björn-Egil</div></div></div></div><div class="im">

_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></blockquote></div><br></div></blockquote></div><br>