> 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
