After forking gecko-dev again for an experiment, I wondered if there was a better way to create a Mozilla app outside the mozilla-central repository. After all, that repository, mirrored as mozilla/gecko-dev on GitHub, is huge. And forking the same repo twice to the same GitHub account (or organization) requires cumbersome workarounds (and workarounds for the workarounds in some cases).
Plus, Mozilla apps don’t necessarily need to modify Gecko. But even when they do, they could share a single fork, with branches for each app, if there was a way to create a Mozilla app that imported gecko-dev as a dependency without having to live inside a fork of gecko-dev itself.
So I created an example app that does just that. It happens to use a shallow Git submodule to import gecko-dev, but it could use a Git subtree or any other dependency management tool.
The build process touches only one file in the gecko-dev subdirectory: it creates a symlink to the parent (app) directory to work around the limitation that Mozilla app directories must be subdirectories of gecko-dev.
To try it for yourself, clone the mykmelez/mozilla-app repo and build it:
git clone --recursive --shallow-submodules https://github.com/mykmelez/mozilla-app
cd mozilla-app/
./mach build && ./mach run
You should see a window like this:
And your clone will contain the app’s files, the gecko-dev submodule directory, and an obj directory containing the built app:
> ls
LICENSE app.mozbuild components gecko-dev modules moz.configure obj
app branding confvars.sh mach moz.build mozconfig
Caveats:
The app builds Gecko from source, so you still need Mozilla build prerequisites. On some platforms, you can install these via ./mach bootstrap
.
I’ve only tested it on Mac, but it probably works on Linux, and it probably doesn’t work on Windows (because of the symlink).
Although the Mozilla application framework is mature and robust, it isn’t explicitly generalized for use beyond Firefox anymore, and it could change or break at any time.
Impressive, Myk. Since sub-repositories are not well-liked in Mercurial (officially a “feature of last resort”), this may be an interesting advantage of git over hg.
(I still prefer hg, though.)
Your observation about Mozilla no longer being generalized for use beyond Firefox matches one of those bits of unease I have about becoming obsolete: I built a good career on XUL and XPCOM, and I’m getting the sense they’re no longer loved. I’m of course happy that they dumped CVS as a version control system… but on practically every other aspect of working with Mozilla code, “best practices” are changing faster than I can keep up. Which is scary, because it’s always been my job to keep whatever codebase I work with compatible with Mozilla…