<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><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><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">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>On Jan 25, 2013, at 11:05 , Björn-Egil Dahlberg <<a href="mailto:wallentin.dahlberg@gmail.com">wallentin.dahlberg@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">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>
_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>http://erlang.org/mailman/listinfo/erlang-questions<br></blockquote></div><br></body></html>