Open Bug 988938 Opened 6 years ago Updated 2 years ago

Integrate building addons into moz.build

Categories

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

defect

Tracking

(Not tracked)

People

(Reporter: gfritzsche, Unassigned)

References

Details

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
gps, can you point me to the rules the addon manager uses?
Flags: needinfo?(gps)
Not a high priority right now.
Assignee: georg.fritzsche → nobody
Component: Client: Desktop → Build Config
Product: Firefox Health Report → Core
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).
Flags: needinfo?(gps)
Summary: Integrate building the test experiment addons into the build process → Integrate building addons into moz.build
No longer blocks: telex
Duplicate of this bug: 1061778
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.
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?
Flags: needinfo?(gps)
I'm not sure we even need to declare anything for addons besides the directory to make an addon out of.
(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.
(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.
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.
Flags: needinfo?(gps)
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.
See Also: → 1240676
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.