Adding a way to disable debug fission.

Adding a way to disable debug fission.

Pointed out that you may want to disable debug fission if;
 * your tooling (distcc, ccache) is too old for debug fission support,
 * you want to use an older gdb,
 * you want to ship a binary containing debug symbols, or
 * you hate things getting faster.

BUG=352046

[mithro-old, 2014-03-18 15:58:37]

Hi peeps,

Another debug fission change. This one makes it so people who hate speed can
disable debug fission :P

Tim

[mithro-old, 2014-03-18 15:59:12]

Hi peeps,

Another debug fission change. This one makes it so people who hate speed can
disable debug fission :P

Tim

[Nico, 2014-03-18 16:01:46]

Can't people who hate it just do GYP_DEFINES=binutils_version=0 ?

[mithro-old, 2014-03-18 16:03:56]

On 2014/03/18 16:01:46, Nico (on GMT time Mar 15 - 24) wrote:
> Can't people who hate it just do GYP_DEFINES=binutils_version=0 ?

I'm not sure? How does the GYP_DEFINES overrides work? 

It is probably nicer to have a proper named value for it incase other things
depend on the binutil versions?

[Nico, 2014-03-18 16:28:14]

On 2014/03/18 16:03:56, mithro wrote:
> On 2014/03/18 16:01:46, Nico (on GMT time Mar 15 - 24) wrote:
> > Can't people who hate it just do GYP_DEFINES=binutils_version=0 ?
> 
> I'm not sure? How does the GYP_DEFINES overrides work? 

If you say 'foo%' in a variables block, the '%' means it's overridable via gyp
defines (which you can set via the GYP_DEFINES env var or via gyp's -D flag).

> It is probably nicer to have a proper named value for it incase other things
> depend on the binutil versions?

In general yes, but disabling fission should be a rare exception I think, so I
wouldn't spend too much time on making that use case super nice.

[mithro-old, 2014-03-18 16:32:17]

On 2014/03/18 16:28:14, Nico (on GMT time Mar 15 - 24) wrote:
> On 2014/03/18 16:03:56, mithro wrote:
> > On 2014/03/18 16:01:46, Nico (on GMT time Mar 15 - 24) wrote:
> > > Can't people who hate it just do GYP_DEFINES=binutils_version=0 ?
> > 
> > I'm not sure? How does the GYP_DEFINES overrides work? 
> 
> If you say 'foo%' in a variables block, the '%' means it's overridable via gyp
> defines (which you can set via the GYP_DEFINES env var or via gyp's -D flag).
> 
> > It is probably nicer to have a proper named value for it incase other things
> > depend on the binutil versions?
> 
> In general yes, but disabling fission should be a rare exception I think, so I
> wouldn't spend too much time on making that use case super nice.

Since this patch already exists now, do you think its worth landing?

[mithro-old, 2014-03-18 16:32:26]

On 2014/03/18 16:28:14, Nico (on GMT time Mar 15 - 24) wrote:
> On 2014/03/18 16:03:56, mithro wrote:
> > On 2014/03/18 16:01:46, Nico (on GMT time Mar 15 - 24) wrote:
> > > Can't people who hate it just do GYP_DEFINES=binutils_version=0 ?
> > 
> > I'm not sure? How does the GYP_DEFINES overrides work? 
> 
> If you say 'foo%' in a variables block, the '%' means it's overridable via gyp
> defines (which you can set via the GYP_DEFINES env var or via gyp's -D flag).
> 
> > It is probably nicer to have a proper named value for it incase other things
> > depend on the binutil versions?
> 
> In general yes, but disabling fission should be a rare exception I think, so I
> wouldn't spend too much time on making that use case super nice.

Since this patch already exists now, do you think its worth landing? It seems to
work...

Tim

[Nico, 2014-03-18 16:34:06]

The cost of a patch is more having it in the tree then writing the patch,
no?


On Tue, Mar 18, 2014 at 4:32 PM, <mithro@mithis.com> wrote:

> On 2014/03/18 16:28:14, Nico (on GMT time Mar 15 - 24) wrote:
>
>> On 2014/03/18 16:03:56, mithro wrote:
>> > On 2014/03/18 16:01:46, Nico (on GMT time Mar 15 - 24) wrote:
>> > > Can't people who hate it just do GYP_DEFINES=binutils_version=0 ?
>> >
>> > I'm not sure? How does the GYP_DEFINES overrides work?
>>
>
>  If you say 'foo%' in a variables block, the '%' means it's overridable
>> via gyp
>> defines (which you can set via the GYP_DEFINES env var or via gyp's -D
>> flag).
>>
>
>  > It is probably nicer to have a proper named value for it incase other
>> things
>> > depend on the binutil versions?
>>
>
>  In general yes, but disabling fission should be a rare exception I think,
>> so I
>> wouldn't spend too much time on making that use case super nice.
>>
>
> Since this patch already exists now, do you think its worth landing? It
> seems to
> work...
>
> Tim
>
> https://codereview.chromium.org/203153005/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[mithro-old, 2014-03-18 16:37:03]

True, this file is a bit of a monster already.

We should probably put some type of documentation somewhere about how to
disable this?

Tim


On 19 March 2014 03:34, Nico Weber <thakis@chromium.org> wrote:

> The cost of a patch is more having it in the tree then writing the patch,
> no?
>
>
> On Tue, Mar 18, 2014 at 4:32 PM, <mithro@mithis.com> wrote:
>
>> On 2014/03/18 16:28:14, Nico (on GMT time Mar 15 - 24) wrote:
>>
>>> On 2014/03/18 16:03:56, mithro wrote:
>>> > On 2014/03/18 16:01:46, Nico (on GMT time Mar 15 - 24) wrote:
>>> > > Can't people who hate it just do GYP_DEFINES=binutils_version=0 ?
>>> >
>>> > I'm not sure? How does the GYP_DEFINES overrides work?
>>>
>>
>>  If you say 'foo%' in a variables block, the '%' means it's overridable
>>> via gyp
>>> defines (which you can set via the GYP_DEFINES env var or via gyp's -D
>>> flag).
>>>
>>
>>  > It is probably nicer to have a proper named value for it incase other
>>> things
>>> > depend on the binutil versions?
>>>
>>
>>  In general yes, but disabling fission should be a rare exception I
>>> think, so I
>>> wouldn't spend too much time on making that use case super nice.
>>>
>>
>> Since this patch already exists now, do you think its worth landing? It
>> seems to
>> work...
>>
>> Tim
>>
>> https://codereview.chromium.org/203153005/
>>
>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.