On Fri, Oct 2, 2015 at 9:08 AM, Randell Jesup <rje...@jesup.org> wrote:
> >On Thu, Oct 1, 2015 at 10:25 PM, Mike Hommey <m...@glandium.org> wrote: > > > >> On Thu, Oct 01, 2015 at 10:10:39PM -0700, Gregory Szorc wrote: > >> > Currently, the Firefox build system builds C++ tests by > >> > default. This adds extra time to builds for something that a > >> > significant chunk of developers don't care about because they don't > >> > run them. > >> > > >> > An easy way to get faster builds is to disable C++ tests by default > >> > (requiring a mozconfig entry to enable them - which would be enabled > in > >> > automation, of course). A more involved solution is to build them on > >> > demand, when tests are executed (unless a build option says to build > them > >> > like today). > >> > > >> > I was curious if Gecko developers (the audience I perceive that > >> > cares about them the most) would be generally opposed to disabling > >> > building C++ tests by default. If not, we can go with an easy > >> > solution (and require people who care to add a mozconfig entry). If > >> > so, we go with the harder solution. > >> > > >> > Is disabling building C++ tests by default a reasonable change? > >> > >> I don't think it is worth the effort. Specifically, we're not really > >> equiped to actually do it currently, and all in all, it's not taking > that > >> much of the build time relative to all the other stuff. The one C++ test > >> that has a significant build time impact is gtest, and we're already > >> skipping it. > > This is a relevant comment. > > >> I'm more interested in growing the faster-make backend to deal with C++ > >> compilation in a sane way than working around the recursive-make > >> deficiencies like this. > > > >+10. > > > >When I do build Gecko, I need the C++ unit tests, so this wouldn't save > >me time at all. Are these tests being built every time someone does an > >incremental build or just when someone changes something in the test? > > They're being *built* each time if anything they depend on changes, I > believe, on every incremental build. Ones that don't depend on anything > that changed don't seem to be built. > > Most devs who build/rebuild firefox will not run the cpp unittests from > that build. Even those of us who do use them don't generally do it on > each build cycle for testing something locally; often it's more of a > pre-checkin pass. So disabling (or deferring) building them locally on > "./mach build" could be a small win for 99% of developers - though a > very small one usually; rebuilding the signaling unit tests after a file > they depend on changed (5 separate unittests) appears to have taken > around 0.05 seconds. If I touch all the cpp files for the > webrtc/mtransport tests (rare outside of clobber), it adds about 1.5-2 > seconds (local 4-year-old XEON desktop linux, building >20 unittests). > > For a clobber build rebuilding all the cpp unittests for the tree could > be noticable however. > > Because the win is small, it shouldn't be a priority, but requiring > something like --enable-cpp-tests should be ok to do (and of course > automation would do that) if/when someone finds time. > > >If the latter, then this seems like it's of pretty small value since > >most builds are incremental. If the former, then this seems to point > >to a problem in the build system. > > It appears to be the latter; I just poked something in editor and it > didn't rebuild any of the cpp unittests. > > >Reading Sylvestre's mail, it seems like there is some thought to > >disable them on at least some automation? I would be strongly opposed > >to this. C++ unit tests are the main test suite for WebRTC, so this > >would be bad. > > Sylvestre seems to be thinking about moving them to a separate suite, > and disabling *running* them in every cycle of automation (which wasn't > the request above). Also, they are already a separate testsuite > (cppunit) IIRC; they no longer run as part of the build itself. > > We very much need our cppunit tests to get run when things that might > break them change. That most certainly isn't everything, note. > > One smart thing that *could* be done for automation (and save a *bunch* > of VM/tester time) would be to not re-run cppunit tests that didn't get > rebuilt - since inbound/etc do incremental builds by default, many > checkins rebuild few or none of the cppunit tests, so running the same > executable again has limited value (not none, but limited). It's not clear to me that whether the CPP unit tests getting rebuild is a good proxy for whether they need to be rerun, given shared libraries and the like. -Ekr _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
