First of all, thanks for raising this. Its definitely a problem that
needs fixing.
I am not convinced by your approach though. In a few months from now
disabling WebRTC is like calling for the DOM or JS or CSS to be disabled
in local developer builds. It will become a natural part of the core Web
platform.
I would like to propose the opposite approach:
- Remove all conditional feature configuration from configure. WebRTC et
al are always on. Features should be disabled dynamically (prefs), if at
all.
- Reduce configure settings to choice of OS and release or developer.
- Require triple super-reviews (hand signed, in blood) for any changes
to configure.
- Make parts of the code base more modular and avoid super include files
cross modules (hello LayoutUtils.h).
Rationale:
Its not slow for you to build WebRTC. Its slow for you to have it build
over and over. Almost every time I pull from mozilla-central, someone
touched configure and I have to rebuild from scratch, which is
infuriating (argh!). Minimizing changes to configure and banning static
defines for feature management would solve that. If we make sure major
subsystems like WebRTC can stand on their own, you will take a hit
building it one time, and then occasionally as the team lands changes.
Its a pretty small team, so the amount of code they can possibly check
in is actually pretty small. You will see churn all over the three when
you pull, but you won't have to rebuild the entire Universe every time
you pull.
What do you think?
Andreas
Mike Hommey wrote:
Hi everyone,
There's been a lot of traction recently about our builds getting slower
and what we could do about it, and what not.
Starting with bug 904979, I would like to change the way we're thinking
about default flags and options. And I am therefore opening a discussion
about it.
The main thing bug 904979 does is to make release engineering builds (as
well as linux distros, palemoon, icecat, you name it) use a special
--enable-release configure flag to use flags that we deem necessary for
a build of Firefox, the product. The flip side is that builds without
this flag, which matches builds from every developer, obviously, would
use flags that make the build faster. For the moment, on Linux systems,
this means disabling identical code folding and dead code removal (which,
while they make the binary size smaller, increase link time), and
forcing the use of the gold linker when it's available but is not system
default. With bug 905646, it will mean enabling -gsplit-dwarf when it's
available, which make link time on linux really very much faster (<4s
on my machine instead of 30s). We could and should do the same kind
of things for other platforms, with the goal of making linking
libxul.so/xul.dll/XUL faster, making edit-compile-edit cycles faster.
If that works reliably, for instance, we should for instance use
incremental linking. Please feel free to file Core::Build Config bugs
for what you think would help on your favorite build platform (and if
you do, for better tracking, make them depend on bug 904979).
That being said, this is not the discussion I want to have here, that
was merely an introduction.
The web has grown in the past few years, and so has our code base, to
support new technologies. As Nathan noted on his blog[1] disabling
webrtc calls for great build time improvements. And I think it's
something we should address by a switch in strategy.
- How many people are working on webrtc code?
- How many people are working on peripheral code that may affect webrtc?
- How many people are building webrtc code they're not working on and
not using?
I'm fairly certain the answer to the above is that the latter population
is much bigger than the other two, by probably more than an order of
magnitude.
So here's the discussion opener: why not make things like webrtc (I'm
sure we can find many more[2]) opt-in instead of opt-out, for local,
developer builds? What do you think are good candidates for such a
switch?
Mike
1.
https://blog.mozilla.org/nfroyd/2013/08/15/better-build-times-through-configury/
2. and we can already start with ICU, because it's built and not even
used. And to add injury to pain, it's currently built without
parallelism (and the patch to make it not do so was backed out).
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
