Re: Disabling C++ tests by default?

[Ehsan Akhgari]

On 2015-10-04 10:39 PM, Jonas Sicking wrote:

On Fri, Oct 2, 2015 at 1:03 PM, Ehsan Akhgari  wrote:

On 2015-10-02 2:42 PM, Jonas Sicking wrote:


It might still mean that we can save time on tryserver if we only
build these by default if the user has opted in to running the
relevant tests.

I agree with Gregory. I really don't see much value in building these
binaries by default. For the people that use them often enough that
they are worth having, adding a line to mozconfig is easy enough.



There is one concrete advantage to building them, which is if your change
ends up breaking some of them, you'll know immediately and you can fix it
much faster than it you find out about it on the try server and/or on
inbound.


But isn't this why we have the feature of choosing which tests to run
on tryserver? Of course, any time you turn off any test, or any
platform, you run the risk of not finding out you broke something
until you push to inbound.

But we've deemed the cost savings of running fewer try servers worth it.


They are indeed similar, but in one case we're talking saving 16 seconds 
versus saving hundreds of hours of machine time, so we don't need to use 
the same solution to both problems.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling C++ tests by default?

[Jonas Sicking]

On Fri, Oct 2, 2015 at 1:03 PM, Ehsan Akhgari  wrote:
> On 2015-10-02 2:42 PM, Jonas Sicking wrote:
>>
>> It might still mean that we can save time on tryserver if we only
>> build these by default if the user has opted in to running the
>> relevant tests.
>>
>> I agree with Gregory. I really don't see much value in building these
>> binaries by default. For the people that use them often enough that
>> they are worth having, adding a line to mozconfig is easy enough.
>
>
> There is one concrete advantage to building them, which is if your change
> ends up breaking some of them, you'll know immediately and you can fix it
> much faster than it you find out about it on the try server and/or on
> inbound.

But isn't this why we have the feature of choosing which tests to run
on tryserver? Of course, any time you turn off any test, or any
platform, you run the risk of not finding out you broke something
until you push to inbound.

But we've deemed the cost savings of running fewer try servers worth it.

/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling C++ tests by default?

[Eric Rescorla]

On Thu, Oct 1, 2015 at 10:25 PM, Mike Hommey  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.
>
> 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? 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.

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.

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling C++ tests by default?

[Sylvestre Ledru]

Le 02/10/2015 07:10, Gregory Szorc a écrit :
> 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.
>
> Is disabling building C++ tests by default a reasonable change?
>
I was going to send the same email. :)

To me, this should be moved into a dedicated testuite, we should not run
them
at each build, especially at some tests seem to be pretty specific
(nsAlertsIconListener, TestMD4, etc)
or unlikely to fail (string_util, stringprintf, TestVector (!),
TestTypedEnum, etc).
I am not even sure to see the value for some of them.

> How much time does it save?
I tried on a recent workstation, serial execution, it took about 2m30s.

Sylvestre
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling C++ tests by default?

[Randell Jesup]

>On Thu, Oct 1, 2015 at 10:25 PM, Mike Hommey  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

Re: Disabling C++ tests by default?

[Jonas Sicking]

It might still mean that we can save time on tryserver if we only
build these by default if the user has opted in to running the
relevant tests.

I agree with Gregory. I really don't see much value in building these
binaries by default. For the people that use them often enough that
they are worth having, adding a line to mozconfig is easy enough.

This also seems independent on other build system improvements. Either
way we'd save by not building these files.

/ Jonas


On Fri, Oct 2, 2015 at 6:09 AM, Eric Rescorla  wrote:
> On Thu, Oct 1, 2015 at 10:25 PM, Mike Hommey  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.
>>
>> 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? 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.
>
> 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.
>
> -Ekr
> ___
> 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

Re: Disabling C++ tests by default?

[Eric Rescorla]

On Fri, Oct 2, 2015 at 9:08 AM, Randell Jesup  wrote:

> >On Thu, Oct 1, 2015 at 10:25 PM, Mike Hommey  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

Re: Disabling C++ tests by default?

[Ehsan Akhgari]

On 2015-10-02 2:42 PM, Jonas Sicking wrote:

It might still mean that we can save time on tryserver if we only
build these by default if the user has opted in to running the
relevant tests.

I agree with Gregory. I really don't see much value in building these
binaries by default. For the people that use them often enough that
they are worth having, adding a line to mozconfig is easy enough.


There is one concrete advantage to building them, which is if your 
change ends up breaking some of them, you'll know immediately and you 
can fix it much faster than it you find out about it on the try server 
and/or on inbound.



This also seems independent on other build system improvements. Either
way we'd save by not building these files.


Look at it this way.  16 seconds of wall time is pretty easy to save 
with things such as moving more files to unified builds (the unified 
builds project brought down our clobber build times by around 50%!). 
Trading the speed off with people writing code that won't compile on 
their own platform on try/inbound seems like the wrong way to optimize 
the build system.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling C++ tests by default?

[Gregory Szorc]

On Thu, Oct 1, 2015 at 10:12 PM, Kyle Huey  wrote:

> How much time does it save?
>

On my MBP, removing all CPP_UNIT_TESTS from moz.builds (which also stops
the production of a few static libraries):

 -141s CPU time (6831s total, so 2%)
   -16s wall time

`mach build binaries` also consumed a fraction more CPU. But wall time was
within measurement variance.

-16s wall time / 2% isn't much on a 16-17 minute build (on this 2 year old
machine). It will be longer on Windows (because Windows) and on machines
with fewer cores (hopefully you are building with 4+ cores). But it is
still a net reduction. C++ building already scales up to several cores and
uses ~100% CPU. So the only way to make C++ build faster is by not building
so much or building what we have more efficiently (avoiding complex
templates, etc).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling C++ tests by default?

[Bobby Holley]

On Fri, Oct 2, 2015 at 1:03 PM, Ehsan Akhgari 
wrote:

> On 2015-10-02 2:42 PM, Jonas Sicking wrote:
>
>> It might still mean that we can save time on tryserver if we only
>> build these by default if the user has opted in to running the
>> relevant tests.
>>
>> I agree with Gregory. I really don't see much value in building these
>> binaries by default. For the people that use them often enough that
>> they are worth having, adding a line to mozconfig is easy enough.
>>
>
> There is one concrete advantage to building them, which is if your change
> ends up breaking some of them, you'll know immediately and you can fix it
> much faster than it you find out about it on the try server and/or on
> inbound.
>

+1. I often break gtests when refactoring code, and it would be super
annoying to need to wait to find out about them on try. Given that this
impacts me as a bystander and not someone who runs those tests all the
time, I don't think that the right solution is for me to personally opt-in
to the old behavior in all of my mozconfigs.

bholley
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling C++ tests by default?

[Bobby Holley]

Cool - thanks for checking Greg!

On Fri, Oct 2, 2015 at 1:57 PM, Gregory Szorc  wrote:

> On Fri, Oct 2, 2015 at 1:40 PM, Bobby Holley 
> wrote:
>
>> On Fri, Oct 2, 2015 at 1:03 PM, Ehsan Akhgari 
>> wrote:
>>
>>> On 2015-10-02 2:42 PM, Jonas Sicking wrote:
>>>
 It might still mean that we can save time on tryserver if we only
 build these by default if the user has opted in to running the
 relevant tests.

 I agree with Gregory. I really don't see much value in building these
 binaries by default. For the people that use them often enough that
 they are worth having, adding a line to mozconfig is easy enough.

>>>
>>> There is one concrete advantage to building them, which is if your
>>> change ends up breaking some of them, you'll know immediately and you can
>>> fix it much faster than it you find out about it on the try server and/or
>>> on inbound.
>>>
>>
>> +1. I often break gtests when refactoring code, and it would be super
>> annoying to need to wait to find out about them on try. Given that this
>> impacts me as a bystander and not someone who runs those tests all the
>> time, I don't think that the right solution is for me to personally opt-in
>> to the old behavior in all of my mozconfigs.
>>
>
> Objections noted. I won't move forward and will retain status quo for now.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling C++ tests by default?

[Mike Hommey]

On Fri, Oct 02, 2015 at 10:01:45AM -0700, Eric Rescorla wrote:
> > 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.

With the way the build system works currently, an option would be worse,
because if you forget it, then you end up rebuilding everything (because
switching the flag will change autoconf.mk, and virtually everything is
rebuilt when this file changes)

> 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.

They are not rebuilt when shared libraries change.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling C++ tests by default?

[Gregory Szorc]

On Fri, Oct 2, 2015 at 1:40 PM, Bobby Holley  wrote:

> On Fri, Oct 2, 2015 at 1:03 PM, Ehsan Akhgari 
> wrote:
>
>> On 2015-10-02 2:42 PM, Jonas Sicking wrote:
>>
>>> It might still mean that we can save time on tryserver if we only
>>> build these by default if the user has opted in to running the
>>> relevant tests.
>>>
>>> I agree with Gregory. I really don't see much value in building these
>>> binaries by default. For the people that use them often enough that
>>> they are worth having, adding a line to mozconfig is easy enough.
>>>
>>
>> There is one concrete advantage to building them, which is if your change
>> ends up breaking some of them, you'll know immediately and you can fix it
>> much faster than it you find out about it on the try server and/or on
>> inbound.
>>
>
> +1. I often break gtests when refactoring code, and it would be super
> annoying to need to wait to find out about them on try. Given that this
> impacts me as a bystander and not someone who runs those tests all the
> time, I don't think that the right solution is for me to personally opt-in
> to the old behavior in all of my mozconfigs.
>

Objections noted. I won't move forward and will retain status quo for now.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling C++ tests by default?

[Eric Rescorla]

On Fri, Oct 2, 2015 at 3:31 PM, Mike Hommey  wrote:

> On Fri, Oct 02, 2015 at 10:01:45AM -0700, Eric Rescorla wrote:
> > > 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.
>
> With the way the build system works currently, an option would be worse,
> because if you forget it, then you end up rebuilding everything (because
> switching the flag will change autoconf.mk, and virtually everything is
> rebuilt when this file changes)
>
> > 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.
>
> They are not rebuilt when shared libraries change.


Right, but they still need to be *run* when the shared libraries change
in many cases.

-Ekr


> Mike
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling C++ tests by default?

[Ted Mielczarek]

On Fri, Oct 2, 2015, at 04:40 PM, Bobby Holley wrote:
> On Fri, Oct 2, 2015 at 1:03 PM, Ehsan Akhgari 
> wrote:
> 
> > On 2015-10-02 2:42 PM, Jonas Sicking wrote:
> >
> >> It might still mean that we can save time on tryserver if we only
> >> build these by default if the user has opted in to running the
> >> relevant tests.
> >>
> >> I agree with Gregory. I really don't see much value in building these
> >> binaries by default. For the people that use them often enough that
> >> they are worth having, adding a line to mozconfig is easy enough.
> >>
> >
> > There is one concrete advantage to building them, which is if your change
> > ends up breaking some of them, you'll know immediately and you can fix it
> > much faster than it you find out about it on the try server and/or on
> > inbound.
> >
> 
> +1. I often break gtests when refactoring code, and it would be super
> annoying to need to wait to find out about them on try. Given that this
> impacts me as a bystander and not someone who runs those tests all the
> time, I don't think that the right solution is for me to personally
> opt-in
> to the old behavior in all of my mozconfigs.

n.b., gps isn't talking about gtests, those already aren't built by
default unless you run them. He's talking about CPP_UNIT_TESTS.

-Ted
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling C++ tests by default?

[Kyle Huey]

How much time does it save?

- Kyle

On Thu, Oct 1, 2015 at 10:10 PM, 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?
> ___
> 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

Re: Disabling C++ tests by default?

[Mike Hommey]

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.

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.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform