Proposal: we should stop supporting static debug builds

[Dirk Pranke]

Hi all,

We currently do not have any builders on the waterfall that do static debug builds, and on some platforms, at least, such a configuration flat-out

won't work (Windows at least, and I think Android might be broken at the moment, too).

I suggest we officially stop supporting this configuration, and change the default in a GN build to be a component build (i.e., is_component=true).

Arguments for dropping:

- This is the configuration that is widely tested

- This is the configuration we recommend to devs because it produces faster links, i.e, faster build times

- One less configuration to worry about

Arguments against dropping:

- This makes the default GN build configuration less like the configuration we ship to customers

- This might cause us to miss some bugs since static builds won't be tested w/ DEBUG checks (but they aren't today).

We historically weren't really able to change this before, because in a GYP build, we couldn't do a debug shared build plus a release static build in a single out/ build directory. However, we don't need to support GYP dev builds any more, and the bots all explicitly set which mode they want, so it should be safe to change

the GN defaults if we want to.

If we decide that we don't want to change the default and we should still support static debug builds on some platforms, I suggest that we should set up

builders for those configurations, at least on the main waterfalls and probably as part of the CQ as well.

Thoughts? Votes one way or another?

-- Dirk

[Brett Wilson]

I support this change in defaults.

Brett

[John Abd-El-Malek]

I wholeheartedly agree with this (I actually thought this was already the status quo?).. We have enough configs to support that we shouldn't add more, especially ones that aren't on the main waterfall.

For consistency with what we ship, that's what release is for.

By the same token, I don't think we should support release component.

On Tue, Jul 26, 2016 at 12:01 PM, Dirk Pranke <dpr...@chromium.org> wrote:

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Marshall Greenblatt]

The CEF project currently creates static debug builds. There are a few reasons for this:

1. CEF distributes static debug builds and symbols to facilitate debugging of CEF in third-party applications. We could probably switch to Release builds + dcheck_always_on=true + (platform-specific symbol generation args) as an alternative.

2. CEF violates a number of component boundaries [1] which precludes us from building with is_component=true. These violations are necessary to expose functionality to client applications via the API exported by the CEF shared library. We can probably fix this with Chromium changes (add *_EXPORT) but it would remain somewhat fragile since Chromium builds don't share these dependencies.

Would people be open to accepting the changes required to fix #2?

Thanks,

Marshall

[1] https://bitbucket.org/chromiumembedded/cef/issues/1617

 

-- Dirk

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Peter Kasting]

On Tue, Jul 26, 2016 at 12:47 PM, Marshall Greenblatt <magree...@gmail.com> wrote:

2. CEF violates a number of component boundaries [1] which precludes us from building with is_component=true. These violations are necessary to expose functionality to client applications via the API exported by the CEF shared library. We can probably fix this with Chromium changes (add *_EXPORT) but it would remain somewhat fragile since Chromium builds don't share these dependencies.

Would people be open to accepting the changes required to fix #2?

I think we should accept these changes, provided:

* They allowed CEF to move onto a component build, thus getting CEF to use the configuration that normal Chromium debug builds use

* The CEF project was willing to fix the CEF component build if Chromium developers broke it

If those are true, then I think the cost to the project of more EXPORT labels is low, and CEF is an important enough external project that taking these changes is worth it.

It's also possible that some of the functionality in the current CEF APIs should be exposed in a different way that didn't require as many Chromium changes, but that would have to be looked at on a case-by-case basis.

PK

[Brett Wilson]

I am slightly less supportive. If there are just a couple of exports that make your life easier, I think adding them is probably OK. But I don't think in general we should be adding things where a developer can not tell why they're like that by looking at the code and the configurations we build.

Brett

[Peter Kasting]

It would be good to understand how extensive the proposed changes are.

I don't know that I can tell why the existing EXPORTs are like that from our code and configurations, so your objection doesn't bother me, but perhaps that is an indictment of my competence :)

PK 

[Marshall Greenblatt]

Putting this issue aside for the moment, perhaps we're looking at debug and release builds the wrong way. We have debug builds currently (static or not) because they're helpful to developers. What are we doing in debug builds (is_debug=true) that's so different from release builds? Whatever that functionality is, perhaps we can expose it in release builds by adding additional flags (like dcheck_always_on=true), and then there would be no particular need to ever create an is_debug=true build? In that world, what we call a debug build today would really just be an is_component=true build with those additional debugging flags turned on by default.

 

Brett

[Christian Biesinger]

To me, the value of is_debug=true is the ability to usefully run in gdb. That requires symbols and a low optimization level (so that variables don't get optimized out, inlined function don't mess up stack traces and single-stepping, etc. etc.) -- and the latter seems in direct conflict with a release build, no?

-Christian

[Marshall Greenblatt]

On Tue, Jul 26, 2016 at 4:49 PM, Christian Biesinger <cbies...@chromium.org> wrote:

To me, the value of is_debug=true is the ability to usefully run in gdb. That requires symbols and a low optimization level (so that variables don't get optimized out, inlined function don't mess up stack traces and single-stepping, etc. etc.) -- and the latter seems in direct conflict with a release build, no?

If we can make is_debug=true just about optimization level and debug symbols then I don't see why it would conflict with is_component=false (or =true). What is it about is_debug=true currently that makes this more complex, and prompted Dirk's original email?

[Xianzhu Wang]

I'm still using static debug build because I often modify blink core code for which component build doesn't help much to speed up build.

More importantly, in the following scenario:

1. gdb content_shell

2. set some breakpoints

3. run --single-process --run-layout-test some/test

4. examine the execution

5. adjust breakpoints

repeat 3-5 until I find the bug,

static build is slow in step 1 only, while component build is fast in step 1 but is slow in each step 3. For static build, normally I can do other things during step 1; but for component build, the slowness of step 3 interrupts contiguous thoughts during debugging.

Is there a way to let gdb not to unload symbols of dynamic libraries between runs?

Tried 'symbol-file -readnow .../libblink_core.so'. It is much slower than step 1 or 3, and it doesn't speed up step 3.

[Peter Kasting]

On Tue, Jul 26, 2016 at 1:55 PM, Marshall Greenblatt <magree...@gmail.com> wrote:

On Tue, Jul 26, 2016 at 4:49 PM, Christian Biesinger <cbies...@chromium.org> wrote:

To me, the value of is_debug=true is the ability to usefully run in gdb. That requires symbols and a low optimization level (so that variables don't get optimized out, inlined function don't mess up stack traces and single-stepping, etc. etc.) -- and the latter seems in direct conflict with a release build, no?

If we can make is_debug=true just about optimization level and debug symbols then I don't see why it would conflict with is_component=false (or =true). What is it about is_debug=true currently that makes this more complex, and prompted Dirk's original email?

Binary sizes getting so build that the Windows linker OOMs, IIRC.

PK

[Marshall Greenblatt]

OK, that makes sense. But is there something in the configuration complexity itself that makes us want to disallow is_debug=true + is_component=false (to then delete that configuration complexity, I presume)?

 

PK

[Peter Kasting]

If we don't want to build or test a configuration then I think it makes sense not to allow that configuration.  Otherwise, people who use it can get something broken in arbitrary or subtle ways.  Having one less possible configuration on the list would likely make a few things a bit simpler, but for me the former issue is the more important one.

Hence Dirk's comment that, if we want to keep this configuration, we really should be building and testing it.  It's supported or it's not, so let's align the world with whichever way we decide it should be, not straddle the fence.

PK

[Marshall Greenblatt]

How would you go about "not allowing" this configuration in GN? Do you add assert()s in a common gni file? The reason I'm asking is that the matrix of potential configurations is quite large, and I'm already using some combinations in CEF that are not tested by other targets in the Chromium project. If you simply intend to add an assert() then I have no objection, since I can comment that out for my purposes. However, if this is likely to result in wide-scale deletion of existing configuration then I'd like to know that as well so that I can properly weigh the alternatives.

 

PK

[Jeremy Roman]

On Tue, Jul 26, 2016 at 3:23 PM, John Abd-El-Malek <j...@chromium.org> wrote:

I wholeheartedly agree with this (I actually thought this was already the status quo?).. We have enough configs to support that we shouldn't add more, especially ones that aren't on the main waterfall.

For consistency with what we ship, that's what release is for.

By the same token, I don't think we should support release component.

I regularly build release component (in fact, it's my default). It's much faster to build than release static, but isn't nearly as slow to use as debug. I'd be sad to lose it.

I usually only build debug component when I expect to attach gdb or am staring at a stack trace with parts optimized away.

[dan...@chromium.org]

On Tue, Jul 26, 2016 at 3:08 PM, Jeremy Roman <jbr...@chromium.org> wrote:

On Tue, Jul 26, 2016 at 3:23 PM, John Abd-El-Malek <j...@chromium.org> wrote:

I wholeheartedly agree with this (I actually thought this was already the status quo?).. We have enough configs to support that we shouldn't add more, especially ones that aren't on the main waterfall.

For consistency with what we ship, that's what release is for.

By the same token, I don't think we should support release component.

I regularly build release component (in fact, it's my default). It's much faster to build than release static, but isn't nearly as slow to use as debug. I'd be sad to lose it.

I usually only build debug component when I expect to attach gdb or am staring at a stack trace with parts optimized away.

This describes how I work also. I only static build if I'm doing official build for perf testing.

[Dirk Pranke]

Replying to various messages in this thread all at once ...

I think we should continue to support release component, too. It's a fast build, and it works fine to debug things in this configuration, at least on the mac. I don't think we need to set up builders for this configuration, though, because it rarely (if ever) breaks.

The major differences in the debug build are that (a) you get full symbols, (b) _DEBUG is defined, and NDEBUG is not defined; there are are a few other defines that also get enabled that trigger various kinds of validation, and various other compiler flags that enable different checks. The net result is that the debug build is significantly slower than a release+dcheck build. You can get full symbols in release and official builds, but the only way to get all of the other stuff is, unsurprisingly, to set is_debug=true. I would encourage CEF to do a release (or even official) build w/ symbols, and then strip the binaries, which is roughly what we do for Chrome.

I think it's worth figuring out what would need to be different, EXPORT-wise, and why. CEF is and has been a long-standing user of Chromium -- it is the public API we recommend people write against if they don't want to do a full port, after all -- and I think it's fair to put some effort into supporting it. We can even set up builders for it, if that's easy enough to do, IMO.

As to "not allowing" it, in this particular case, I would add an assert(!is_debug || is_component_build) because we don't want people wasting time trying to make this work if there's no reason for it to work.

More generally, there are many, many combinations of flags that are possible that we don't test on the main (or even fyi) waterfall. There are even a number of flags that, by themselves, we don't test on the main waterfall. We do not require waterfall coverage for every config, and I'm not proposing that we change that. I don't even think it would be practical to do so, particularly for all of the flags needed by embedders in different configurations.

This particular configuration is different IMO because it's such a fundamental one (unlike, say, use_cups=false or even enable_nacl=false on windows).

-- Dirk

On Tue, Jul 26, 2016 at 3:08 PM, Jeremy Roman <jbr...@chromium.org> wrote:

[Xianzhu Wang]

On Tue, Jul 26, 2016 at 2:16 PM, Xianzhu Wang <wangx...@chromium.org> wrote:

I'm still using static debug build because I often modify blink core code for which component build doesn't help much to speed up build.

More importantly, in the following scenario:

1. gdb content_shell

2. set some breakpoints

3. run --single-process --run-layout-test some/test

4. examine the execution

5. adjust breakpoints

repeat 3-5 until I find the bug,

static build is slow in step 1 only, while component build is fast in step 1 but is slow in each step 3. For static build, normally I can do other things during step 1; but for component build, the slowness of step 3 interrupts contiguous thoughts during debugging.

Is there a way to let gdb not to unload symbols of dynamic libraries between runs?

Tried 'symbol-file -readnow .../libblink_core.so'. It is much slower than step 1 or 3, and it doesn't speed up step 3.

Have anyone using component debug build encounter the same issue, or already have a solution? I'm reluctant to switch to component debug build with the issue.

[Sunny Sachanandani]

This is what the gdb manual says about reloading symbols: "If the modification time of your symbol file has changed since the last time GDB read its symbols, GDB discards its symbol table, and reads it again." https://ftp.gnu.org/old-gnu/Manuals/gdb-5.1.1/html_node/gdb_17.html#SEC18

[John Abd-El-Malek]

(Similarly trying to reply to a few points at once)

On Tue, Jul 26, 2016 at 3:24 PM, Dirk Pranke <dpr...@chromium.org> wrote:

Replying to various messages in this thread all at once ...

I think we should continue to support release component, too. It's a fast build, and it works fine to debug things in this configuration, at least on the mac. I don't think we need to set up builders for this configuration, though, because it rarely (if ever) breaks.

Ken and I were chatting about this and he timed the link time difference on Linux release component vs Linux release static to be 3s vs 12s. I realize every second count, but IMO this is too small a difference to justify adding a new supported build configuration. Every new config can have some specific benefit, but the bar should be pretty high to add a new supported config.

The major differences in the debug build are that (a) you get full symbols, (b) _DEBUG is defined, and NDEBUG is not defined; there are are a few other defines that also get enabled that trigger various kinds of validation, and various other compiler flags that enable different checks. The net result is that the debug build is significantly slower than a release+dcheck build. You can get full symbols in release and official builds, but the only way to get all of the other stuff is, unsurprisingly, to set is_debug=true. I would encourage CEF to do a release (or even official) build w/ symbols, and then strip the binaries, which is roughly what we do for Chrome.

I think it's worth figuring out what would need to be different, EXPORT-wise, and why. CEF is and has been a long-standing user of Chromium -- it is the public API we recommend people write against if they don't want to do a full port, after all -- and I think it's fair to put some effort into supporting it.

I agree to first find out how many exports we need. IMO Marshall can add as many export calls to the classes as we need. We don't audit and remove ones that are unused in our code.

 

We can even set up builders for it, if that's easy enough to do, IMO.

I don't think we should add new builders at this point for projects outside our repo. That means that we're on the hook for maintaining it, which means having to make changes in other repos and potentially three sided patches.

[Xianzhu Wang]

On Tue, Jul 26, 2016 at 3:37 PM, Sunny Sachanandani <sun...@chromium.org> wrote:

This is what the gdb manual says about reloading symbols: "If the modification time of your symbol file has changed since the last time GDB read its symbols, GDB discards its symbol table, and reads it again." https://ftp.gnu.org/old-gnu/Manuals/gdb-5.1.1/html_node/gdb_17.html#SEC18

 

This seems not the issue I encountered. The step 3 is slow everytime no matter if the symbol file changed. It seems that gdb unload the symbols when the dynamic library is unloaded.

[Dirk Pranke]

Can you split the gdb issue off into a different thread? The numbers you're quoting seem odd to me (I wouldn't expect component to be much slower), but I don't want to have two quite different discussions going on on the same thread.

-- Dirk

[Dirk Pranke]

On Tue, Jul 26, 2016 at 3:48 PM, John Abd-El-Malek <j...@chromium.org> wrote:

(Similarly trying to reply to a few points at once)

On Tue, Jul 26, 2016 at 3:24 PM, Dirk Pranke <dpr...@chromium.org> wrote:

Replying to various messages in this thread all at once ...

I think we should continue to support release component, too. It's a fast build, and it works fine to debug things in this configuration, at least on the mac. I don't think we need to set up builders for this configuration, though, because it rarely (if ever) breaks.

Ken and I were chatting about this and he timed the link time difference on Linux release component vs Linux release static to be 3s vs 12s. I realize every second count, but IMO this is too small a difference to justify adding a new supported build configuration. Every new config can have some specific benefit, but the bar should be pretty high to add a new supported config.

As I attempted to note before, there are different levels of "supported", and I don't think release shared is imposing any particular burden on us (unlike debug static).

 

The major differences in the debug build are that (a) you get full symbols, (b) _DEBUG is defined, and NDEBUG is not defined; there are are a few other defines that also get enabled that trigger various kinds of validation, and various other compiler flags that enable different checks. The net result is that the debug build is significantly slower than a release+dcheck build. You can get full symbols in release and official builds, but the only way to get all of the other stuff is, unsurprisingly, to set is_debug=true. I would encourage CEF to do a release (or even official) build w/ symbols, and then strip the binaries, which is roughly what we do for Chrome.

I think it's worth figuring out what would need to be different, EXPORT-wise, and why. CEF is and has been a long-standing user of Chromium -- it is the public API we recommend people write against if they don't want to do a full port, after all -- and I think it's fair to put some effort into supporting it.

I agree to first find out how many exports we need. IMO Marshall can add as many export calls to the classes as we need. We don't audit and remove ones that are unused in our code.

 

We can even set up builders for it, if that's easy enough to do, IMO.

I don't think we should add new builders at this point for projects outside our repo. That means that we're on the hook for maintaining it, which means having to make changes in other repos and potentially three sided patches.

I'm sorry, I think what I was trying to suggest was unclear. I wouldn't want to build CEF itself, but if CEF needs to set a bunch of flags that aren't

necessarily set in one of the existing configurations, and if we can do a build that has those flags set but doesn't require actual CEF code, I would think *that* would be a reasonable config to build on the waterfall (just like we have builders that test things resembling ChromeCast and CrOS, even though they're not the real configurations for those products).  

-- Dirk

[Xianzhu Wang]

Ok. However, I would like to know if the issue is common, and if yes, this might be a blocking issue of not allowing static debug build.

Based on the response, either the slowness or my scenario is not common. If the latter, then my scenario is a blocking issue of static debug build of myself, then I would have to continue to use static debug build locally though not supported.

[Dominic Mazzoni]

On Tue, Jul 26, 2016 at 3:48 PM John Abd-El-Malek <j...@chromium.org> wrote:

(Similarly trying to reply to a few points at once)

On Tue, Jul 26, 2016 at 3:24 PM, Dirk Pranke <dpr...@chromium.org> wrote:

Replying to various messages in this thread all at once ...

I think we should continue to support release component, too. It's a fast build, and it works fine to debug things in this configuration, at least on the mac. I don't think we need to set up builders for this configuration, though, because it rarely (if ever) breaks.

Ken and I were chatting about this and he timed the link time difference on Linux release component vs Linux release static to be 3s vs 12s. I realize every second count, but IMO this is too small a difference to justify adding a new supported build configuration. Every new config can have some specific benefit, but the bar should be pretty high to add a new supported config.

Are you arguing that release + component should be disallowed, or just that we don't need a builder?

I think 3s vs 12s is a pretty substantial difference when you're talking about an incremental build, like after changing one source file. Also keep in mind that those numbers come from a fast desktop machine - many of us have 2nd or 3rd machines that aren't as fast, and compiling / linking can take twice or three times as long.

[Lambros Lambrou]

Would this proposal affect other builds than Chrome?

For example, the Android remoting_apk target fails when built with is_component_build = true.

When the APK is installed and run, I get this error:

E AndroidRuntime: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/org.chromium.chromoting-1/base.apk"],nativeLibraryDirectories=[/data/app/org.chromium.chromoting-1/lib/arm, /data/app/org.chromium.chromoting-1/base.apk!/lib/armeabi-v7a, /vendor/lib, /system/lib]]] couldn't find "libremoting_client_jni.so"

I don't think we've developed or tested a components build of Chromoting on any platform, because it's not the default and there has never been any reason for us to support it.

[Dirk Pranke]

I'm not sure what you mean by "builds other than Chrome", but perhaps that's also exactly your question.

Yes, the proposal would affect anything in the chromium build, not just the chrome executable. Trying to allow

for some targets but not others might complicate things a fair amount.

We do support component builds on android, generally, so I don't know why remoting wouldn't work, apart

from maybe just never having tried to make it work? (The same goes for the other platforms).

It would also be interesting if we knew we needed to support debug static builds of other subsets of the chrome

build that are used outside of the project (e.g., net, gn, nacl, etc.).

-- Dirk

[John Abd-El-Malek]

On Tue, Jul 26, 2016 at 4:00 PM, Dirk Pranke <dpr...@chromium.org> wrote:

On Tue, Jul 26, 2016 at 3:48 PM, John Abd-El-Malek <j...@chromium.org> wrote:

(Similarly trying to reply to a few points at once)

On Tue, Jul 26, 2016 at 3:24 PM, Dirk Pranke <dpr...@chromium.org> wrote:

Replying to various messages in this thread all at once ...

I think we should continue to support release component, too. It's a fast build, and it works fine to debug things in this configuration, at least on the mac. I don't think we need to set up builders for this configuration, though, because it rarely (if ever) breaks.

Ken and I were chatting about this and he timed the link time difference on Linux release component vs Linux release static to be 3s vs 12s. I realize every second count, but IMO this is too small a difference to justify adding a new supported build configuration. Every new config can have some specific benefit, but the bar should be pretty high to add a new supported config.

As I attempted to note before, there are different levels of "supported", and I don't think release shared is imposing any particular burden on us (unlike debug static).

I guess if we say it's explicitly non-supported. That means to not committing to adding it to waterfall.

 

 

The major differences in the debug build are that (a) you get full symbols, (b) _DEBUG is defined, and NDEBUG is not defined; there are are a few other defines that also get enabled that trigger various kinds of validation, and various other compiler flags that enable different checks. The net result is that the debug build is significantly slower than a release+dcheck build. You can get full symbols in release and official builds, but the only way to get all of the other stuff is, unsurprisingly, to set is_debug=true. I would encourage CEF to do a release (or even official) build w/ symbols, and then strip the binaries, which is roughly what we do for Chrome.

I think it's worth figuring out what would need to be different, EXPORT-wise, and why. CEF is and has been a long-standing user of Chromium -- it is the public API we recommend people write against if they don't want to do a full port, after all -- and I think it's fair to put some effort into supporting it.

I agree to first find out how many exports we need. IMO Marshall can add as many export calls to the classes as we need. We don't audit and remove ones that are unused in our code.

 

We can even set up builders for it, if that's easy enough to do, IMO.

I don't think we should add new builders at this point for projects outside our repo. That means that we're on the hook for maintaining it, which means having to make changes in other repos and potentially three sided patches.

I'm sorry, I think what I was trying to suggest was unclear. I wouldn't want to build CEF itself, but if CEF needs to set a bunch of flags that aren't

necessarily set in one of the existing configurations, and if we can do a build that has those flags set but doesn't require actual CEF code, I would think *that* would be a reasonable config to build on the waterfall

That seems hypothetical at this point, so not sure if it's worth discussing. i.e. what was mentioned by Marshall was adding more EXPORTs.

 

(just like we have builders that test things resembling ChromeCast and CrOS, even though they're not the real configurations for those products).  

That's a bit different, for these we have extra code that we build which is the primary reason we have them on the waterfall.

[John Abd-El-Malek]

On Tue, Jul 26, 2016 at 6:37 PM, Lambros Lambrou <lambros...@chromium.org> wrote:

Would this proposal affect other builds than Chrome?

For example, the Android remoting_apk target fails when built with is_component_build = true.

When the APK is installed and run, I get this error:

E AndroidRuntime: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/org.chromium.chromoting-1/base.apk"],nativeLibraryDirectories=[/data/app/org.chromium.chromoting-1/lib/arm, /data/app/org.chromium.chromoting-1/base.apk!/lib/armeabi-v7a, /vendor/lib, /system/lib]]] couldn't find "libremoting_client_jni.so"

I don't think we've developed or tested a components build of Chromoting on any platform, because it's not the default and there has never been any reason for us to support it.

We're talking about configs that aren't on the waterfall already, and no one suggested removing any existing configs on the waterfall, so this shouldn't impact you given that your testing situation has been fine so far.

 

On Tue, Jul 26, 2016 at 4:06 PM, Dominic Mazzoni <dmaz...@chromium.org> wrote:

On Tue, Jul 26, 2016 at 3:48 PM John Abd-El-Malek <j...@chromium.org> wrote:

(Similarly trying to reply to a few points at once)

On Tue, Jul 26, 2016 at 3:24 PM, Dirk Pranke <dpr...@chromium.org> wrote:

Replying to various messages in this thread all at once ...

I think we should continue to support release component, too. It's a fast build, and it works fine to debug things in this configuration, at least on the mac. I don't think we need to set up builders for this configuration, though, because it rarely (if ever) breaks.

Ken and I were chatting about this and he timed the link time difference on Linux release component vs Linux release static to be 3s vs 12s. I realize every second count, but IMO this is too small a difference to justify adding a new supported build configuration. Every new config can have some specific benefit, but the bar should be pretty high to add a new supported config.

Are you arguing that release + component should be disallowed, or just that we don't need a builder?

I think 3s vs 12s is a pretty substantial difference when you're talking about an incremental build, like after changing one source file. Also keep in mind that those numbers come from a fast desktop machine - many of us have 2nd or 3rd machines that aren't as fast, and compiling / linking can take twice or three times as long.

IMO if we're talking about developer productivity, then adding extra supported configs so that 2nd or 3rd generation machines are useful aren't worth it. The 3-12 second is the worst case scenario for browser_tests. That's the largest test suite which dwarfs the other. As the code is modularized, monolithic targets like this should go away.

[Antoine Labour]

On Tue, Jul 26, 2016 at 3:24 PM, Dirk Pranke <dpr...@chromium.org> wrote:

Replying to various messages in this thread all at once ...

I think we should continue to support release component, too. It's a fast build, and it works fine to debug things in this configuration, at least on the mac. I don't think we need to set up builders for this configuration, though, because it rarely (if ever) breaks.

The major differences in the debug build are that (a) you get full symbols, (b) _DEBUG is defined, and NDEBUG is not defined; there are are a few other defines that also get enabled that trigger various kinds of validation, and various other compiler flags that enable different checks. The net result is that the debug build is significantly slower than a release+dcheck build. You can get full symbols in release and official builds, but the only way to get all of the other stuff is, unsurprisingly, to set is_debug=true. I would encourage CEF to do a release (or even official) build w/ symbols, and then strip the binaries, which is roughly what we do for Chrome.

I think it's worth figuring out what would need to be different, EXPORT-wise, and why. CEF is and has been a long-standing user of Chromium -- it is the public API we recommend people write against if they don't want to do a full port, after all -- and I think it's fair to put some effort into supporting it. We can even set up builders for it, if that's easy enough to do, IMO.

As to "not allowing" it, in this particular case, I would add an assert(!is_debug || is_component_build) because we don't want people wasting time trying to make this work if there's no reason for it to work.

Please do not make it an assert. Maybe a warning if you really think that's useful.

There are some (many, actually) configurations that are not tested on the waterfall that are still useful for developers. For example, libfuzzer targets don't really work with component builds - and it is sometimes needed to build debug fuzzers to be able to debug repro cases.

Antoine

You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Colin Blundell]

Pardon my ignorance, but what kinds of issues cause static builds to fail where component builds would succeed? All the issues I've experienced with differences between the two builds are the other way: a static build succeeds but a component build fails due to missing export macros. PK mentioned one issue: on Windows a static debug build fails to link due to OOM. That's not a subtle issue, and I don't think that that issue on its own indicates that we'd have to disallow static debug builds (but that opinion is arguable).

It's worth pointing also that the component build is not supported on iOS, so a static debug build would still have to be allowed on that platform. I talked to +Sylvain Defresne and while it *might* be possible to support the component build on iOS given recent platform changes, it would be a nontrivial amount of work and there are no imminent plans to try to make it happen.

Thanks,

Colin

[Primiano Tucci]

On Tue, Jul 26, 2016 at 11:48 PM John Abd-El-Malek <j...@chromium.org> wrote:

(Similarly trying to reply to a few points at once)

Ken and I were chatting about this and he timed the link time difference on Linux release component vs Linux release static to be 3s vs 12s. 

I join the train of "don't take away release+component" here. That is my major workflow. I very rarely build debug at all (just for having locals working in gdb), I almost always do release+component. 

On a Z620 w/ SSD linking release+static takes 15 s. for me.

More importantly, linking release+static+symbol_level=2 takes 45s (I often use this for most gdb debugging cases)

In comparison, for the things I work on regularly:

Linking libbase.so in release+static+symbol_level=2 takes 1.07 s.

Linking libtracing.so in release+static+symbol_level=2 takes 0.8 s

So really here we are talking about 15x slowdown for normal cases and 45x slowdown when I need gdb. That's quite a big difference.

As regards the other topic (debug and component), in general I am in favor of making is_component_build implicitly true for debug builds. I'd be pretty nervous, instead, knowing that there is no way to build a full static+debug build. That means that the day that I have a bug which shows up only in static official builds I'll have no way to use gdb to inspect locals.

I believe that having builds that repro only in static build are not that uncommon, if you consider that component builds are the land of ODR violations.

Out of curiosity what is the thing that makes debug+static hard to maintain or prone to breakages? (I could understand the other way round, debug+component) 

[Mark Mentovai]

What does “stop supporting” mean to you?

Don’t intentionally break this configuration. With much of what I work on, I need to see things as closely to what we ship to users as possible. Symbol visibility and the distribution of object code among modules is relevant to this. It does happen periodically that I also need something that is a bit more debuggable than “official” or even “release”, so I want something like -O0 !-DNDEBUG, but I don’t need or want for this to diverge from “release” any further than that. This is exactly what I get today with “static debug,” and I need for this configuration to still work.

What am I working on where this is so relevant? Crash reporting! For crash reporting, module structures, interdependencies, and symbol visibilities are all incredibly relevant, to the point that there’s not much sense in looking at what doesn’t match what end users see. Crash reporting is effectively disabled in all but official builds, which we only ship in a statically-linked configuration, and so statically-linked builds are all that are relevant to me for crash reporter integration into Chrome, even when I need to drop from “official” or “release” down to “debug”.

Mark

[Lucas Gadani]

I use static debug for the same reason when on Linux. I'm ok with the slow linking times when I get much faster attach times on gdb. That's the case even with indexes added to the elf.

I don't think we should intentionally break debug/static builds, but I'm ok with not having it officially supported either. People who use it can mantain/fix it when they need it.