988938 - Integrate building addons into moz.build

Status: NEW

(Firefox Build System :: General, defect, P3)

Description

[Georg Fritzsche [:gfritzsche]]

For the addons we use to test the telemetry experiments, we should:
* have the install.rdf files in the tree
* figure out how to build the addons as part of our normal build

Comment 1

[Georg Fritzsche [:gfritzsche]]

gps, can you point me to the rules the addon manager uses?

Comment 2

[Benjamin Smedberg]

Not a high priority right now.

Comment 3

[Gregory Szorc [:gps]]

toolkit/mozapps/extensions/test/Makefile.in.

Sadly, adding a Makefile.in for browser/experiments will require a clobber (adding new Makefile.in files requires a clobber).

Given that building add-ons is responsible for some of the grosser hacks in the build system, I'd like to have a moz.build mechanism for defining add-ons.

We might be able to tackle the XPI_NAME issue as well (which blocks a *lot* of build system work, such as converting JSM installs to moz.build).

Comment 5

[(not currently active) Ted Mielczarek]

I'm not sure that bug 1061778 and the XPI_NAME stuff really overlap. The stuff from toolkit/mozapps/extensions/test is just zipping up directories of files, nothing more.

Comment 6

[Nathan Froyd [:froydnj]]

I looked some at this today, probably not enough to understand all the complexity and special cases involved.  Complete strawman proposal for how the moz.build should look, completely unimplemented:

ADDONS += ['addon1', 'addon2']

# Various flags like NO_JS_MANIFEST should be hung off the addon object.
ADDONS['addon1'].no_js_manifest = True
ADDONS['addon1'].chrome_file_format = 'flat'
# ... and so forth.

# Not entirely sure how specifying additional files for the addon (i.e. DIST_FILES) should work.
# I think the end goal should be each addon has its own build manifest that's responsible for
# installing the addon's files in the proper location.  So that means we'd need to hang DIST_FILES,
# EXTRA_COMPONENTS, EXTRA_PP_COMPONENTS, etc. off of the addon object.
#
# I *think* this also means parsing jar.mn is required for determining all the files we have to
# install.
ADDONS['addon1'].dist_files += ['install.rdf', ...]

# Strawman name for what was EXTRA_COMPONENTS.
ADDONS['addon1'].components += ['mymodule.js', ...]
# Ditto for preprocessed files.
ADDONS['addon1'].pp_components += ['myppmodule.js', ...]

# specialpowers (possibly other addons) needs to be installed in additional places.
ADDONS['addon1'].extra_install_locations += ['!/testing/mochitest/extensions', ...]

Sound plausible?

Comment 7

[Mike Hommey [:glandium]]

I'm not sure we even need to declare anything for addons besides the directory to make an addon out of.

Comment 8

[Nathan Froyd [:froydnj]]

(In reply to Mike Hommey [:glandium] from comment #7)
> I'm not sure we even need to declare anything for addons besides the
> directory to make an addon out of.

So you want to just have the files in the srcdir exactly mirror how we would build the addon?  That seems plausible, but I'm not sure how well that works with reftest, or perhaps the default theme.

I mean, it sounds pretty, but I don't see immediately how that works with some of the addon setups we have.

Comment 9

[Joshua Cranmer [:jcranmer]]

(In reply to Mike Hommey [:glandium] from comment #7)
> I'm not sure we even need to declare anything for addons besides the
> directory to make an addon out of.

I'm sure Lightning might care to disagree (it's an addon with several non-trivial make steps and even some binary code, yuck). Something as complex as Lightning might be out-of-scope, but the chatzilla and DOMi repositories may have similar concerns.

I'll admit I'm not particularly sure what rules, etc., would be effective.

Comment 10

[Gregory Szorc [:gps]]

I think adding EXTRA_COMPONENTS, etc off of ADDONS is overkill. Let's go for the simplest solution of defining which files belong where in the XPI. This allows us to create XPIs properly, using MozJarrer. We can work backwards and port support for build rules for these files later. How about:

ADDONS['name'].installs.lib += ['foo.jsm']
ADDONS['name'].installs.resources += ['bar.jsm']

We can hang things other than "installs" on there later. Of course, we can use the "!" path magic to define paths in objdir.

Comment 11

[Mike Hommey [:glandium]]

I think for "complex" cases, we can have them "stage" their content with the currently existing stuff, and define that the addon directory is the objdir where they are staged.