Emscripten dependencies are * LLVM+clang, only the very latest stable version, which updates every 6 months. We don't test against older versions currently. * Python 2.7.x * SpiderMonkey shell or node.js
Build times are reasonable for small to medium projects, but on large projects we have known issues with long compile times. For example it takes over a minute compile 100,000 lines of C++ in BananaBread. - Alon ----- Original Message ----- > From: "Ting-Yuan Huang" <[email protected]> > To: "Jonas Sicking" <[email protected]> > Cc: [email protected], "Andreas Gal" <[email protected]>, > [email protected], "Tim Guan-tin > Chien" <[email protected]>, "Alon Zakai" <[email protected]> > Sent: Monday, April 29, 2013 8:04:17 PM > Subject: Re: [b2g] About committing codes generated by emscripten > > > How much work would that be? And how would it impact our build > > times? > > It depends on what to be compiled. Basically it's clang + an LLVM > backend and > should be in the same order of normal, native builds using gcc, if > not faster. > I used it to compile libchewing and it took 9.0/5.3 seconds to > configure/compile, > while the native build took 4.9/6.9. I've no idea why the > configuration process > took longer but that should be insignificant if compared to compile > time in > large projects. > > ----- Original Message ----- > From: "Jonas Sicking" <[email protected]> > To: "Tim Guan-tin Chien" <[email protected]> > Cc: [email protected], "Andreas Gal" > <[email protected]>, [email protected] > Sent: Tuesday, April 30, 2013 4:11:00 AM > Subject: Re: [b2g] About committing codes generated by emscripten > > In general I absolutely hate having "compiled code" checked into the > tree. > > It makes it harder to hack on the code and it always results in code > getting out-of-sync with the source. > > From a legal point of view we should probably also always keep the > source > code in the same repository as the compiled code. > > If emscripten-generated code is turning into more of a common > occurrence I > think we should consider adding emscripten-compilation to the build > process. > > How much work would that be? And how would it impact our build times? > > / Jonas > On Apr 10, 2013 2:27 AM, "Tim Chien" <[email protected]> wrote: > > > First of all, no documentation on Github states that one must > > manually > > downstream the source to Gecko if she/he want to modify the code. > > https://github.com/andreasgal/PhoneNumber.js > > > > While there is a comment in the Gecko source states that "Don't > > modify this > > code" > > > > https://mxr.mozilla.org/mozilla-central/source/dom/phonenumberutils/PhoneNumber.jsm > > one must do some Bugzilla archaeology to figure out the proper way > > to > > double land the code. Not to mention the hassle of manually > > sync/commit/push the code in two source repo. > > > > Combining the two points above, this effectively limit the bus > > factor to > > only people capable of doing all that. It slows us down too. > > > > It also hurts the ability for others to reuse PhoneNumberJS too. > > Given the > > fact the complex commit rule of up-most upstream repo, if any other > > project > > would like to use the code, fork away with a simple click on Github > > and > > never contribute back, is easier. > > > > I am not saying people shouldn't have different way of using Github > > and any > > other tools, but if the process ended up shoot us in the foot, it > > would be > > worth to rethink if there is a better process out there. > > > > > > > > > > On Wed, Apr 10, 2013 at 4:36 PM, Andreas Gal > > <[email protected]> > > wrote: > > > > > > > > I think that code was not updated because its scheduled for > > > removal as > > the > > > code wandered into Gecko, where we update it the same way. Help > > > me > > > understand why this doesn't scale? I don't see how that follows > > > from your > > > argument, even if it was accurate. > > > > > > Andreas > > > > > > On Apr 10, 2013, at 1:29 AM, Tim Chien <[email protected]> > > > wrote: > > > > > > > Andreas, > > > > > > > > With all due respect, this process doesn't scale. As an > > > > evidence, > > > PhoneNumberJS have since out-dated in Gaia. > > > > I've long filed a bug on that [1], but again, such housekeeping > > > > task > > was > > > never prioritized during triage. > > > > > > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=847797 > > > > > > > > That said, find a new way to incorporate external code doesn't > > > > block us > > > from using them though. > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 4:19 PM, Andreas Gal > > > > <[email protected]> > > > wrote: > > > > > > > > I recommend putting up a github repo with the original code and > > > > build > > > scripts, and then you can check in generated code into gaia. I > > > did that > > for > > > the phone number library. Make sure every change goes upstream > > > into the > > > github repo, and then update the generated code. > > > > > > > > Andreas > > > > > > > > On Apr 10, 2013, at 1:10 AM, Ting-Yuan Huang > > > > <[email protected]> > > wrote: > > > > > > > > > Hi, > > > > > > > > > > If I got some C/C++/whatever codes compiled into javascripts > > > > > by > > > emscripten, is it a good idea to only commit the generated > > > javascripts? > > > Obviously it's terrible to embed the whole c++-to-js routines > > > into the > > b2g > > > build process that everyone must spend their time compile the > > > codes from > > > scratch. To what extent should I add the details? Is a README > > > good enough > > > or should I write a one-click script (that may sometimes be > > > broken due to > > > changes to the upstreams and act like a README)? > > > > > > > > > > Thanks. > > > > > _______________________________________________ > > > > > dev-b2g mailing list > > > > > [email protected] > > > > > https://lists.mozilla.org/listinfo/dev-b2g > > > > > > > > _______________________________________________ > > > > dev-b2g mailing list > > > > [email protected] > > > > https://lists.mozilla.org/listinfo/dev-b2g > > > > > > > > > > > > > > > > -- > > > > Tim Guan-tin Chien, Senior Front-end Dev., Mozilla Corp. > > > > (Taiwan) > > > > > > _______________________________________________ > > > dev-b2g mailing list > > > [email protected] > > > https://lists.mozilla.org/listinfo/dev-b2g > > > > > > > > > > > -- > > Tim Guan-tin Chien, Senior Front-end Dev., Mozilla Corp. (Taiwan) > > _______________________________________________ > > dev-b2g mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-b2g > > > _______________________________________________ > dev-gaia mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-gaia > _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
