>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). -- Randell Jesup, Mozilla Corp remove "news" for personal email _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
