(Incrementally) package omnijar during `mach build`
Categories
(GeckoView :: General, enhancement)
Tracking
(Not tracked)
People
(Reporter: nalexander, Unassigned)
References
(Blocks 1 open bug)
Details
Right now, on Android we invoke stage-package as a separate tier. It's slow and single-threaded.
What would it take to finally do this packaging as part of mach build properly?
If we restricted to just producing the omnijar, could we completely capture the inputs and do this with proper dependency tracking? Potentially even incrementally?
:glandium, your thoughts on what the restrictions are would really help. Thanks!
|
||
Comment 1•3 months ago
|
||
The build system doesn't know enough to do that at the moment. Most things rely on directories in dist/bin to be filled by the build, without knowing what those files are beforehand. Even the build system doesn't know what those files are before actually building because some of them may come from l10n repos, and also because we don't process jar.mn files until during the build.
The code also doesn't handle incremental updates.
It's slow
Define slow.
|
Reporter | |
Comment 2•3 months ago
|
||
(In reply to Mike Hommey [:glandium] from comment #1)
The build system doesn't know enough to do that at the moment. Most things rely on directories in dist/bin to be filled by the build, without knowing what those files are beforehand. Even the build system doesn't know what those files are before actually building because some of them may come from l10n repos, and also because we don't process jar.mn files until during the build.
My memory is hazy, but isn't this only partially true? Don't we process jar.mn files at configure-time in the FasterMake backend?
The code also doesn't handle incremental updates.
Aye, but it could learn.
It's slow
Define slow.
In automation, a recent build had android-stage-package take 11.3s. Locally, mach build android-stage-package is ~3s, although surely some of that is overhead that could be amortized.
Description
•