Open Bug 1371159 Opened 2 years ago Updated 24 days ago
Add a --disable-many-things build to automation
It's easy to inadvertently break the build when features are disabled. It would be good to have a build on automation that disables lots of features. Ones off the top of my head: * --disable-gecko-profiler (this option doesn't exist, but it should) * --disable-webrtc There are probably a lot more. Jan and Petr, do you have any suggestions of other features to disable based on your experience of what things tend to break?
Not really. At this moment for 52.1ESR we do disable followings: --disable-updater --disable-tests --disable-crashreporter These should be probably revised. See: https://github.com/oracle/solaris-userland/blob/master/components/desktop/firefox/Makefile For the trunk I don't disable anything. But I don't have it fully it working yet.
I don't really think this is a worthwhile endeavor. I'd rather we just remove build options that tend to break a lot.
For example, in bug 1315896 we removed --disable-gamepad, and just made unsupported platforms build a stub gamepad backend.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #3) > For example, in bug 1315896 we removed --disable-gamepad, and just made > unsupported platforms build a stub gamepad backend. ... which might as well break.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #2) > I don't really think this is a worthwhile endeavor. I'd rather we just > remove build options that tend to break a lot. What about the profiler? It's not supported on all platforms.
I'm sure Landry has an opinion here as well, see comment 0.
(In reply to Mike Hommey [:glandium] from comment #4) > (In reply to Ted Mielczarek [:ted.mielczarek] from comment #3) > > For example, in bug 1315896 we removed --disable-gamepad, and just made > > unsupported platforms build a stub gamepad backend. > > ... which might as well break. Sure. Anything that's not in our CI is likely to break. I don't think "make every possible build configuration Tier-1" is feasible, though.
> I don't think "make > every possible build configuration Tier-1" is feasible, though. That's a mischaracterization of what I want from this bug. I'm interested in a single extra configuration that can test the disabling of a handful of components. The profiler is one I've had trouble with myself on multiple occasions. I suspect there are a small number of other components that regularly cause problems. One of my aims in filing this bug is to determine what those other components are.
If there are common build configurations used by packagers or Firefox developers, then I think it is worth having CI coverage for them so we cause as little disruption as possible. Very few things are worse than your build randomly breaking, especially when you find out about the breakage days or even months after it was caused and you've already paged out most knowledge around the changed thing that broke it, making a fix more time consuming. Of course, having N>>1 build configurations is an even worse problem. I'd rather we trend towards N-1 supported build configurations. But, yeah, that's hard.
NetBSD and OpenBSD implicitly use --disable-skia-gpu. powerpc*, sparc*, etc. implicitly use --disable-ion.
As for the build options we use (for the distributed binaires) that could gain from 'upstream' coverage (besides being able to disable the profiler, because i think that's the single biggest cause of build breakage we had in the past years, that and mismatching types) would be building against systemwide libraries: nss, nspr, sqlite, bz2, hunspell, cairo, ffi, icu..
Just as we're talking about it, the build is broken again on platforms without the profiler, cf https://bugzilla.mozilla.org/show_bug.cgi?id=1335461#c50 Just a misplaced #if/#endif/closing brace.. but that's depressing. And would be caught by automation if there was a build without the profiler.
non profiler builds busted again, cf https://bugzilla.mozilla.org/show_bug.cgi?id=1375398 ..
I think we should have a build job that disable unified builds. This would allow to immediately find the missing #include that keeps creeping up whenever the unified builds get tweaked. I keeps popping up, and is typically a massive waste of time for everybody
(In reply to Jean-Yves Avenard [:jya] from comment #14) > I think we should have a build job that disable unified builds. > > This would allow to immediately find the missing #include that keeps > creeping up whenever the unified builds get tweaked. > > I keeps popping up, and is typically a massive waste of time for everybody Tweaking unified builds is not something that happens frequently. See bug 1251181 anyways.
Tweaking the unified builds setting, maybe not. Adding or removing new files however that could change how files are combined happens much more often and every time it has happened we had to rework the missing headers.
You need to log in before you can comment on or make changes to this bug.