On 11/14/2014 1:54 PM, Gregory Szorc wrote:
For reference, here is a partial list of things that are broken or
inefficient:
To add: the package-manifest.in is nothing short of a footgun. If you
add a new component, component manifest, xpidl module, non-omni.ja file,
etc., you will break releases if you forget to add it to the package
manifest. If you add in to a shared component like, say, toolkit, you
potentially have to modify up to seven package manifests to make it
work. And if it's not exercised in a test, you'll virtually guarantee
that no one will notice it missing (this caused us to stop collecting
Telemetry data until someone said "oy, why don't we have any telemetry
data?").
I've tried building a shared toolkit package manifest before, but the
current ones are an orgy of partially-duplicated insanity and, given
that I don't have build systems set up for b2g or android, it's more or
less beyond me to do the requisite testing to make anything stick.
* jar.mn files aren't processed efficiently as part of the build (we
process them every build and this isn't a no-op). (jar.mn files are
used to define l10n files)
* The Makefile hackery for nearly everything packaging and l10n
related is eye-gouging bad. See mozapps/installer/packager.mk and
toolkit/locales/Makefile.in if you dare. There is essentially a shadow
build system related to packaging and l10n repacks that makes
optimizing or changing things extremely difficult.
* Testing around packaging and l10n is horrible to non-existent. l10n
jobs can break and we won't find out until a train uplift.
* Very little developer visibility and understanding of how packaging
works, especially l10n packaging (although I think this is getting
better with code moving in tree).
Despite being the comm-central build system peer, I have no idea:
1. How l10n repacks work
2. How to test an l10n repack manually
3. Where the buildbot code for l10n repacks lives
4. Where the status results of l10n repacks may be found
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
