1371159 - Add a --disable-many-things build to automation

Status: NEW

(Firefox Build System :: General, enhancement)

Description

[Nicholas Nethercote [inactive]]

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?

Comment 1

[Petr Sumbera]

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.

Comment 2

[(not currently active) Ted Mielczarek]

I don't really think this is a worthwhile endeavor. I'd rather we just remove build options that tend to break a lot.

Comment 3

[(not currently active) Ted Mielczarek]

For example, in bug 1315896 we removed --disable-gamepad, and just made unsupported platforms build a stub gamepad backend.

Comment 4

[Mike Hommey [:glandium]]

(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.

Comment 5

[Nicholas Nethercote [inactive]]

(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.

Comment 6

[Nathan Froyd [:froydnj]]

I'm sure Landry has an opinion here as well, see comment 0.

Comment 7

[(not currently active) Ted Mielczarek]

(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.

Comment 8

[Nicholas Nethercote [inactive]]

> 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.

Comment 9

[Gregory Szorc [:gps]]

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.

Comment 10

[Jan Beich]

NetBSD and OpenBSD implicitly use --disable-skia-gpu.
powerpc*, sparc*, etc. implicitly use --disable-ion.

Comment 11

[Landry Breuil (:gaston)]

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..

Comment 12

[Landry Breuil (:gaston)]

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.

Comment 13

[Landry Breuil (:gaston)]

non profiler builds busted again, cf https://bugzilla.mozilla.org/show_bug.cgi?id=1375398 ..

Comment 14

[Jean-Yves Avenard [:jya]]

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

Comment 15

[Mike Hommey [:glandium]]

(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.

Comment 16

[Jean-Yves Avenard [:jya]]

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.