On 16.08.2013 16:23, Andrew McCreight wrote: > > ----- 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.
I would expect that the number of build failures increases if people disable parts of the code locally. Everything works for them, but when they push to m-i, things don't build any longer because the patches are incomplete. Best regards Thomas > > 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 >>> dev-platform@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-platform >> >> -- >> Adam Roach >> Principal Platform Engineer >> a...@mozilla.com >> +1 650 903 0800 x863 >> _______________________________________________ >> 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
