----- Original Message ----- > I think the key argument against this approach is that system components > are never truly isolated. Sure, some of them can be compiled out and > still produce a working system. That doesn't mean that testing without > those components is going to have good test coverage. > > What I'm worried about, if we start disabling various modules, is that > we're going to have regressions that go unnoticed on developer systems, > blow up on m-i, and then take a _long_ time to track down. We already > have m-i closed for about four hours a day as it is, frequently during > prime working hours for a substantial fraction of Mozilla's > contributors. Further varying developers' local build environments from > those of the builders will only make this problem worse.
I imagine that most people only run tests locally that are related to the code they are working on, so it doesn't seem like it would make things any worse. Andrew > > /a > > On 8/16/13 04:32, 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 > > [email protected] > > https://lists.mozilla.org/listinfo/dev-platform > > > -- > Adam Roach > Principal Platform Engineer > [email protected] > +1 650 903 0800 x863 > _______________________________________________ > dev-platform mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
