On 29/04/2013 22:11, Jonas Sicking wrote:
In general I absolutely hate having "compiled code" checked into the tree.
That's why Gecko should be rewritten in JS only. No 'compiled code' in
the tree anymore :)
If we think about the problem like Gecko code with source in C++ and a
objdir then it sounds to me that we should have a local copy of the
source code somewhere in Gaia too. So if we need a patch in the original
source code then it can be landed in Gaia while people tries to upstream
the changes. Then the build script will live in Gaia and would generate
the 'compiled' version of the lib from here.
If we need a new version of the lib then the one in Gaia will be updated
with the needed patches applied.
Also the build script will be part of Gaia too and there will be always
a compiled version of the lib commited in the repo. The build script
will be re-run manually from the src/ dir when needed.
P.S: Julien, thanks for thinking about me and my old Debian stable.
Hopefully the new version is coming soon (4/5th of May) with Python 2.7
by default! :) I will not have to use some tricks anymore :)
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
