[chromium-dev] Re: variant definitions in the .gyp files
Steven Knight wrote:
> 'official': {
> 'defines': ['OFFICIAL_BUILD'],
> # Make sure units of code and data go in their own section,
> # and then GC them in the linker to remove unreferenced data
> # and code. Currently gold doesn't support --gc-sections,
> # so you'll have to build with the original GNU ld.
> 'cflags': ['-ffunction-sections', '-fdata-sections'],
> 'linkflags': ['-Wl,--gc-sections'],
> },
I agree with what Tom said regarding 'official' as a variant.
variants will need to have the same restrictions that configurations
do, meaning that they won't be able to influence 'sources' or
'actions' or 'rules' or anything else in input.py's
non_configuration_keys list. For 'official', we do need the ability
to make changes to some non_configuration_keys, so this won't fly.
'official' will need to remain a GYP generation-time tunable.
> 'symbols': {
> 'cflags': ['-g'],
> },
For Chrome's purposes, I don't see why we would ever want to build
without symbols. Either you're a developer and symbols are handy in a
direct way, or you're building an official release build and symbols
are handy for crash reporting. In what cases would -g0 be useful?
Mark
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: variant definitions in the .gyp files
On Thu, Apr 2, 2009 at 7:48 PM, Mark Mentovai wrote:
>
> Steven Knight wrote:
>> 'official': {
>> 'defines': ['OFFICIAL_BUILD'],
>> # Make sure units of code and data go in their own section,
>> # and then GC them in the linker to remove unreferenced data
>> # and code. Currently gold doesn't support --gc-sections,
>> # so you'll have to build with the original GNU ld.
>> 'cflags': ['-ffunction-sections', '-fdata-sections'],
>> 'linkflags': ['-Wl,--gc-sections'],
>> },
>
> I agree with what Tom said regarding 'official' as a variant.
> variants will need to have the same restrictions that configurations
> do, meaning that they won't be able to influence 'sources' or
> 'actions' or 'rules' or anything else in input.py's
> non_configuration_keys list. For 'official', we do need the ability
> to make changes to some non_configuration_keys, so this won't fly.
> 'official' will need to remain a GYP generation-time tunable.
>
>> 'symbols': {
>> 'cflags': ['-g'],
>> },
>
> For Chrome's purposes, I don't see why we would ever want to build
> without symbols. Either you're a developer and symbols are handy in a
> direct way, or you're building an official release build and symbols
> are handy for crash reporting. In what cases would -g0 be useful?
We did this for speed, not generating debug symbols in all of your
objects, and linking together a massive binary, can cut down the build
time significantly. Basically for a lot of people release is
something they can build and use, and debug is something they will use
for development. The stack traces / debugging / etc in a optimized
build isn't that great anyway, so basically what you generally want is
something like:
debug - symbols
release - no symbols
official - symbols
but it is nice to be able to build a release w/ symbols if you want, a
good example is for running valgrind, etc.
>
> Mark
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: variant definitions in the .gyp files
One answer: try server.
On Thu, Apr 2, 2009 at 2:49 PM, Dean McNamee wrote:
>
> On Thu, Apr 2, 2009 at 7:48 PM, Mark Mentovai wrote:
>>
>> Steven Knight wrote:
>>> 'official': {
>>> 'defines': ['OFFICIAL_BUILD'],
>>> # Make sure units of code and data go in their own section,
>>> # and then GC them in the linker to remove unreferenced data
>>> # and code. Currently gold doesn't support --gc-sections,
>>> # so you'll have to build with the original GNU ld.
>>> 'cflags': ['-ffunction-sections', '-fdata-sections'],
>>> 'linkflags': ['-Wl,--gc-sections'],
>>> },
>>
>> I agree with what Tom said regarding 'official' as a variant.
>> variants will need to have the same restrictions that configurations
>> do, meaning that they won't be able to influence 'sources' or
>> 'actions' or 'rules' or anything else in input.py's
>> non_configuration_keys list. For 'official', we do need the ability
>> to make changes to some non_configuration_keys, so this won't fly.
>> 'official' will need to remain a GYP generation-time tunable.
>>
>>> 'symbols': {
>>> 'cflags': ['-g'],
>>> },
>>
>> For Chrome's purposes, I don't see why we would ever want to build
>> without symbols. Either you're a developer and symbols are handy in a
>> direct way, or you're building an official release build and symbols
>> are handy for crash reporting. In what cases would -g0 be useful?
>
> We did this for speed, not generating debug symbols in all of your
> objects, and linking together a massive binary, can cut down the build
> time significantly. Basically for a lot of people release is
> something they can build and use, and debug is something they will use
> for development. The stack traces / debugging / etc in a optimized
> build isn't that great anyway, so basically what you generally want is
> something like:
>
> debug - symbols
> release - no symbols
> official - symbols
>
> but it is nice to be able to build a release w/ symbols if you want, a
> good example is for running valgrind, etc.
>
>>
>> Mark
>>
>> >
>>
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: variant definitions in the .gyp files
Marc-Antoine Ruel wrote: > One answer: try server. OK, I'm sold. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: variant definitions in the .gyp files
Stephen, I've added coverage to the Mac side (and part way there on the Linux side). I have LGTMs but haven't landed it yet. It's similar to your changes but not exactly the same. http://codereview.chromium.org/56136 http://codereview.chromium.org/57083 How can we not klobber each other here? jrg On Thu, Apr 2, 2009 at 1:15 PM, Mark Mentovai wrote: > > Marc-Antoine Ruel wrote: > > One answer: try server. > > OK, I'm sold. > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: variant definitions in the .gyp files
What's the workflow for enabling coverage in this model? "gclient runhooks --force -Dcoverage=1" and then re-start XCode? That doesn't seem natural for the Linux side, but I could live with it. Linux devs: comments? --SK On Thu, Apr 2, 2009 at 1:45 PM, John Grabowski wrote: > Stephen, I've added coverage to the Mac side (and part way there on the > Linux side). I have LGTMs but haven't landed it yet. It's similar to your > changes but not exactly the same. > http://codereview.chromium.org/56136 > http://codereview.chromium.org/57083 > > How can we not klobber each other here? > > jrg > > > On Thu, Apr 2, 2009 at 1:15 PM, Mark Mentovai wrote: > >> >> Marc-Antoine Ruel wrote: >> > One answer: try server. >> >> OK, I'm sold. >> >> >> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: variant definitions in the .gyp files
Steven Knight wrote: > What's the workflow for enabling coverage in this model? "gclient runhooks > --force -Dcoverage=1" and then re-start XCode? > > That doesn't seem natural for the Linux side, but I could live with it. > Linux devs: comments? I think that the variant model is a stronger way to handle coverage. Once we do have a variant-based model to handle coverage, the only thing missing from John's work would be the coverage-running target. We could easily retain that target, unconditionally, and just have the script be a no-op (or fail) when run on a coverage-free variant. Long-term, we might even want to integrate the coverage runner stuff more directly into GYP, the way we have done with test runners. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: variant definitions in the .gyp files
I like the variant model as well. Perhaps I can rephrase my question. How can we not klobber each other here? Should I land what I've got, and you can adapt it once you implement variants? Or should I throw it away? jrg On Thu, Apr 2, 2009 at 2:29 PM, Mark Mentovai wrote: > > Steven Knight wrote: > > What's the workflow for enabling coverage in this model? "gclient > runhooks > > --force -Dcoverage=1" and then re-start XCode? > > > > That doesn't seem natural for the Linux side, but I could live with it. > > Linux devs: comments? > > I think that the variant model is a stronger way to handle coverage. > > Once we do have a variant-based model to handle coverage, the only > thing missing from John's work would be the coverage-running target. > We could easily retain that target, unconditionally, and just have the > script be a no-op (or fail) when run on a coverage-free variant. > > Long-term, we might even want to integrate the coverage runner stuff > more directly into GYP, the way we have done with test runners. > > Mark > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: variant definitions in the .gyp files
John Grabowski wrote: > I like the variant model as well. Perhaps I can rephrase my question. > How can we not klobber each other here? Should I land what I've got, and > you can adapt it once you implement variants? Or should I throw it away? Please commit what you already have. We haven't implemented anything for variants yet. Steven suggested it this morning and I asked him to start this thread so that we could come to a consensus on design. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
