build system refactoring plan

49 views
Skip to first unread message

Yuren Ju

unread,
Aug 9, 2013, 2:15:21 AM8/9/13
to dev-...@lists.mozilla.org, Vivien Nicolas, James Lal, Tim Chien
Hi all,

we had a long discussion [1] for single language in our build system.
and I would like to make it come ture :-)

Here is my plan:
1. make GAIA_DIR/build/*.js compatibility both with node.js & xpcshell
2. add new target build-test to run unit test for build/*.js
2-1. for node.js we run unit test by mocha
2-2. for xpcshell we run unit test in a firefox extension by mocha
(using mocha browser mode to test xpcshell speicific code)
3. re-write build/*.py to javascript
4. extract some logic from makefile to build/*.js

at the end we will get a makfile contains few code only for executing
javascript in build/, and then we will have many js modules which can
reuse in node.js and firefox extension :D

BTW, we can use grunt.js to replace makefile, but it will make build
system depend on node.js, we can keep discussing it.

I'll file a dozen issues for this, feel free to take it!

[1] https://groups.google.com/forum/#!topic/mozilla.dev.gaia/OGMptI67qE4

Yuren Ju

unread,
Aug 12, 2013, 6:34:50 AM8/12/13
to Alexandre poirot, dev-...@lists.mozilla.org
CC dev-gaia back :-)

my first problem is I have no idea how to use commonjs in xpcshell.
try r.js for AMD is okay, for commonjs I think it will work if I
import 'resource://gre/modules/commonjs/toolkit/loader.js' but seems
not.

still studying for xpcshell.

- Yuren

On Mon, Aug 12, 2013 at 4:57 PM, Alexandre poirot <poiro...@gmail.com> wrote:
> I can most likely help you find your way on the xpcshell/firefox-addon side.
>
> I'm first thinking about the commonjs module loader being shipped in Firefox
> via the add on SDK.
> That would allow us to first convert our existing is codebase from "a soup
> of js files" to a set of well defined commonjs modules.
>
> Then also thanks to the addon SDK, we can replace nsIFile usages by path and
> fs modules from the add on SDK. These modules are meant to expose same API
> than node one!
>
> Otherwise we should operate incrementally and avoid reimplementing build
> system from scratch in node. As we should be able to easily refactor our
> xpcshell codebase to a set of commonjs modules depending on node-compatible
> dependencies.
>
> Also, that would be handy to use a whiteboard flag.
>
> Thanks Yuren for driving this forward!!
>> _______________________________________________
>> dev-gaia mailing list
>> dev-...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-gaia

Yuren Ju

unread,
Aug 13, 2013, 11:51:01 PM8/13/13
to Alexandre poirot, dev-...@lists.mozilla.org

John O'Duinn

unread,
Aug 14, 2013, 5:41:15 PM8/14/13
to Yuren Ju, dev-b...@lists.mozilla.org, dev-...@lists.mozilla.org, Alexandre poirot
hi Yuren;

I'm super happy to see work like this start on b2g build system. We do
literally thousands of builds daily, so every little helps! As the
gecko code is shared with Firefox+Fennec, I'm looping in dev-builds
newsgroup, so BuildConfig and RelEng folks can follow along, and make
sure all our shared Firefox+Fennec+B2G build+test infrastructure
continues to work when your changes land.

Let me know if there's anything we can do to help.
John.

Yuren Ju

unread,
Aug 20, 2013, 3:06:16 AM8/20/13
to John O'Duinn, dev-b...@lists.mozilla.org, dev-...@lists.mozilla.org, Alexandre poirot
Hi John,

I have filed some bugs on bugzilla:
https://bugzilla.mozilla.org/showdependencygraph.cgi?id=905096

for short term, I don't modify any target of makefile, so I think all
shared infrastucture will work fine.
but after refactoring build/*.js done, we can consider to reduce makefile code.

and it would be great if I can test build on TBPL before those commits
for build system land.
Reply all
Reply to author
Forward
0 new messages