Should GN debug builds be component builds by default?

[Brett Wilson]

I'm finishing up the Windows component build. Normally we would toggle the debug bots over so this configuration is tested.

But then I started to wonder whether a debug build should always just be a component build by default. Almost everybody sets this, and I can't think of a strong reason to do otherwise. The option to do a non-component debug build would still be there, but you'd have to explicitly turn it off.

Does anybody have strong opinions to the contrary?

Brett

[Nico Weber]

Personally, I think that both Debug and Release should be component by default.

More generally, I think gn should match gyp until the transition is complete to make things less confusing for everyone.

[Scott Graham]

The gyp build doesn't do that only because it would mean parsing the input twice.

I'd like it if gn defaulted Debug to shared and Release to static.

[Nico Weber]

On Mon, May 4, 2015 at 3:29 PM, Scott Graham <sco...@chromium.org> wrote:

The gyp build doesn't do that only because it would mean parsing the input twice.

No, the gyp build doesn't do that because xcode and vc couldn't do that historically. Gyp already parses the input twice for release and debug.

[Nico Weber]

On Mon, May 4, 2015 at 3:32 PM, Nico Weber <tha...@chromium.org> wrote:

On Mon, May 4, 2015 at 3:29 PM, Scott Graham <sco...@chromium.org> wrote:

The gyp build doesn't do that only because it would mean parsing the input twice.

No, the gyp build doesn't do that because xcode and vc couldn't do that historically. Gyp already parses the input twice for release and debug.

…or generates the output twice, I suppose. You're right, doing this in gyp would mean parsing twice.

[Ryan Gonzalez]

On Mon, May 4, 2015 at 5:29 PM, Scott Graham <sco...@chromium.org> wrote:

The gyp build doesn't do that only because it would mean parsing the input twice.

I'd like it if gn defaulted Debug to shared and Release to static.

IMO, That's horrible and bug-prone and overly black-magic-ish. Too much like CMake.

 

On Mon, May 4, 2015 at 2:45 PM, Nico Weber <tha...@chromium.org> wrote:

Personally, I think that both Debug and Release should be component by default.

More generally, I think gn should match gyp until the transition is complete to make things less confusing for everyone.

On Mon, May 4, 2015 at 2:44 PM, Brett Wilson <bre...@chromium.org> wrote:

I'm finishing up the Windows component build. Normally we would toggle the debug bots over so this configuration is tested.

But then I started to wonder whether a debug build should always just be a component build by default. Almost everybody sets this, and I can't think of a strong reason to do otherwise. The option to do a non-component debug build would still be there, but you'd have to explicitly turn it off.

Does anybody have strong opinions to the contrary?

Brett

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

--

Ryan

[ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong.

http://kirbyfan64.github.io/

 

[Brett Wilson]

I don't think release should default to component. The main reason to do a release build is for perf testing or something, and component build is inappropriate for that. Few people do release builds, and if you bother to do this, it should default to be close to the final product. If it was up to me, would make release do the extra "official_build" optimization too (obviously a separate discussion).

I don't think it's confusing to diverge from GYP in this case. I've actually had people be confused that the gn debug build *isn't* a component build. Everybody has set this GYP define and don't even think about it any more. Plus: this configuration matches what we do on the bots (all debug builds are component, all release builds are static).

Brett

[Nico Weber]

On Mon, May 4, 2015 at 3:51 PM, Brett Wilson <bre...@chromium.org> wrote:

I don't think release should default to component. The main reason to do a release build is for perf testing or something

I do all my development builds in Release on all platforms. They link faster.

 

, and component build is inappropriate for that. Few people do release builds

Citation needed? It's what I recommend to everyone I've mentored (for the reason mentioned above) :-)

If you want to do perf testing, you need to do an official branded build anyways.

[Scott Graham]

I think it's because Windows has a debugger, whereas on other platforms it never seems worth it.

So assuming we don't want table driven defaults, I guess static by default for all configs (in service of matching gyp) is probably best.

[Brett Wilson]

On Mon, May 4, 2015 at 4:01 PM, Scott Graham <sco...@chromium.org> wrote:

I think it's because Windows has a debugger, whereas on other platforms it never seems worth it.

So assuming we don't want table driven defaults, I guess static by default for all configs (in service of matching gyp) is probably best.

Okay.

[Dirk Pranke]

I don't think we should change release builds to component by default. I would be fine w/ defaulting debug to component, but I am also fine w/ leaving the defaults alone (i.e., static for both).

I can also see sense in leaving things alone for now, and then changing things once gyp is gone.

-- Dirk

[Evan Martin]

On Mon, May 4, 2015 at 3:54 PM, Nico Weber <tha...@chromium.org> wrote:

On Mon, May 4, 2015 at 3:51 PM, Brett Wilson <bre...@chromium.org> wrote:

I don't think release should default to component. The main reason to do a release build is for perf testing or something

I do all my development builds in Release on all platforms. They link faster.

Is this due to the debug info in the .o's?  I recall gyp has some "fastbuild" thing that disables debug info but also disables optimizations.

Perhaps it's useful to take a step back from this notion that there must be exactly two build types and that their names are debug and release.  It seems to me you want one which is "I am hackin' on the code", where you want fast build times and debug info if possible, and you also certainly need some way to build the one that users get, and then finally you want some way to build states that are in between the above two.

PS: I think google3 debug mode builds tests in components but non-tests as single files.

[Nico Weber]

On Tue, May 5, 2015 at 9:25 AM, Evan Martin <ev...@google.com> wrote:

On Mon, May 4, 2015 at 3:54 PM, Nico Weber <tha...@chromium.org> wrote:

On Mon, May 4, 2015 at 3:51 PM, Brett Wilson <bre...@chromium.org> wrote:

I don't think release should default to component. The main reason to do a release build is for perf testing or something

I do all my development builds in Release on all platforms. They link faster.

Is this due to the debug info in the .o's?

On OS X, no. OS X keeps debug info in the .os and doesn't link them (kind of like fission, except without the extra file). It has a separate debug info loader, but debuggers also know how to go the the .o file to get debug info at debugger-start time. For that reason, release builds on OS X include symbols and you can debug them, you just get an "variable optimized out" every now and then. Release just generates way less code, which is why it's faster to link.

On Linux, it's probably because of both effects, with debug info dominating. (I don't remember if we do -ffunction-sections and dead code stripping in release only, but that speeds up linking too since less code needs to be written back to disk.)

[Brett Wilson]

On Tue, May 5, 2015 at 9:25 AM, 'Evan Martin' via gn-dev <gn-...@chromium.org> wrote:

On Mon, May 4, 2015 at 3:54 PM, Nico Weber <tha...@chromium.org> wrote:

On Mon, May 4, 2015 at 3:51 PM, Brett Wilson <bre...@chromium.org> wrote:

I don't think release should default to component. The main reason to do a release build is for perf testing or something

I do all my development builds in Release on all platforms. They link faster.

Is this due to the debug info in the .o's?  I recall gyp has some "fastbuild" thing that disables debug info but also disables optimizations.

Yes, in GN this is "symbol_level" = 0|1|2 with the inverse meaning as the GYP one.

 

Perhaps it's useful to take a step back from this notion that there must be exactly two build types and that their names are debug and release.  It seems to me you want one which is "I am hackin' on the code", where you want fast build times and debug info if possible, and you also certainly need some way to build the one that users get, and then finally you want some way to build states that are in between the above two.

PS: I think google3 debug mode builds tests in components but non-tests as single files.

 

I recently made imports work from the args files. The idea is that you can do "gn args out/foo" and then type

  import("//build/config/official_release.gni")

and then get all the flags associated with that configuration (adding more or changing them yourself below if you want). Your build will stay in sync as the definition of the official release build changes.

We're going to let the conversion settle more before recommending people do this. Right now we're prioritizing keeping the GN and GYP builds in sync with each other on the bots. When that's less of an issue, we can optimize for keeping your build and the bot in sync.

Brett