> - Remove all conditional feature configuration from configure. WebRTC et al > are always > on. Features should be disabled dynamically (prefs), if at all.
Note that Fabrice has seen sizable memory-usage wins on B2G by disabling non-web features such as printing and XUL. That alone is, in my mind, a very strong argument for keeping at least some of these configure options around. On Fri, Aug 16, 2013 at 2:43 AM, Andreas Gal <andreas....@gmail.com> wrote: > > 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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
