GN: Generate appropriate .dSYMs for .frameworks and .apps

GN: Generate appropriate .dSYMs for .frameworks and .apps

.dSYM file names should match the name of the bundle they were generated for:
For "Chromium.app" "Chromium.app.dSYM" should be used, and for
"Chromium Framework.framework" "Chromium Framework.framework.dSYM".

.dSYM bundles are generated by the template("mac_toolchain"), which
knows nothing of the .app/.framework suffixes, so we're moving the
.dSYMs to the proper location when forming the .app/.framework bundles.

BUG=699153

[themblsha, 2017-03-07 17:25:30]

Description was changed from

==========
GN: Generate appropriate .dSYMs for .frameworks and .apps

.dSYM file names should match the name of the bundle they were generated for:
For "Chromium.app" "Chromium.app.dSYM" should be used, and for
"Chromium Framework.framework" "Chromium Framework.framework.dSYM".

.dSYM bundles are generated by the template("mac_toolchain"), which
knows nothing of the .app/.framework suffixes, so we're moving the
.dSYMs to the proper location when forming the .app/.framework bundles.

BUG=699153
==========

to

==========
GN: Generate appropriate .dSYMs for .frameworks and .apps

.dSYM file names should match the name of the bundle they were generated for:
For "Chromium.app" "Chromium.app.dSYM" should be used, and for
"Chromium Framework.framework" "Chromium Framework.framework.dSYM".

.dSYM bundles are generated by the template("mac_toolchain"), which
knows nothing of the .app/.framework suffixes, so we're moving the
.dSYMs to the proper location when forming the .app/.framework bundles.

BUG=699153
==========

[themblsha, 2017-03-07 17:25:30]

mblsha@yandex-team.ru changed reviewers:
+ dpranke@chromium.org, rsesek@chromium.org

[Robert Sesek, 2017-03-07 18:14:33]

What's the rationale? I decided against doing this when implementing dSYM
generation because of the output extension issue.

[Dirk Pranke, 2017-03-07 22:35:01]

I defer to rsesek@ here.

[Robert Sesek, 2017-03-16 21:52:35]

not lgtm for two reasons:

1) This breaks the //chrome:chrome_dsym_archive target, which is built as part
of chrome in is_chrome_branded.

2) With this patched in, the build never stabilizes. Build chrome_framework
once, then build it again; ninja should do no work the second time, instead it
runs a bunch of steps. Moving files in GN doesn't work well because the input of
one step is then marked as "missing" for the next step.

[themblsha, 2017-03-17 15:50:58]

https://codereview.chromium.org/2731313004/diff/20001/build/toolchain/mac/BUI...
File build/toolchain/mac/BUILD.gn (right):

https://codereview.chromium.org/2731313004/diff/20001/build/toolchain/mac/BUI...
build/toolchain/mac/BUILD.gn:175: if (defined(invoker.dsym_name)) {
This doesn't actually work, as it seems that I need to forward the |dsym_name|
through all the templates. But the template("mac_toolchain") seems to be
instantiated through the "tool" and I'm not sure how to achieve that.

Maybe you could advice? :-)

[Robert Sesek, 2017-03-17 16:59:36]

https://codereview.chromium.org/2731313004/diff/20001/build/toolchain/mac/BUI...
File build/toolchain/mac/BUILD.gn (right):

https://codereview.chromium.org/2731313004/diff/20001/build/toolchain/mac/BUI...
build/toolchain/mac/BUILD.gn:175: if (defined(invoker.dsym_name)) {
On 2017/03/17 15:50:58, themblsha wrote:
> This doesn't actually work, as it seems that I need to forward the |dsym_name|
> through all the templates. But the template("mac_toolchain") seems to be
> instantiated through the "tool" and I'm not sure how to achieve that.
> 
> Maybe you could advice? :-)

I think this is because tool()s are actually special entities in GN that only
inherit specific tool variables (see `gn help tool`).

This may be fairly tricky to pipe through, because technically the link
tool/step doesn't actually know where in the output bundle structure the binary
goes. That's handled by the bundle_data/create_bundle steps, which occur after.

[Robert Sesek, 2017-03-17 17:14:08]

Random idea: Maybe the linker tool needs a debug_output_path?

[themblsha, 2017-03-17 17:24:53]

On 2017/03/17 17:14:08, Robert Sesek wrote:
> Random idea: Maybe the linker tool needs a debug_output_path?

As an additional parameter? Currenty linker seems to be invoked through
shared_library / executable targets, and it seems that I need to patch GN in
order to add debug_output_path to them.

[Robert Sesek, 2017-03-17 17:54:17]

On 2017/03/17 17:24:53, themblsha wrote:
> On 2017/03/17 17:14:08, Robert Sesek wrote:
> > Random idea: Maybe the linker tool needs a debug_output_path?
> 
> As an additional parameter? Currenty linker seems to be invoked through
> shared_library / executable targets, and it seems that I need to patch GN in
> order to add debug_output_path to them.

Yes, I think this may require a change to GN because the
shared_library/executable/other linker tool types don't place their outputs in
the bundle directly, they go into places like
"obj/chrome/chrome_helper_app_executable/Google Chrome Helper". At that time,
the linker target doesn't know where in the bundle the file ultimately will end
up, so it does seem like it will require passing more information to the linker
tool().

I don't really have a clear path to fixing this laid out -- it's going to take
some fiddling to figure out the best solution.

[themblsha, 2017-03-24 12:48:40]

On 2017/03/17 17:54:17, Robert Sesek (OOO til Mar-29) wrote:
> On 2017/03/17 17:24:53, themblsha wrote:
> > On 2017/03/17 17:14:08, Robert Sesek wrote:
> > > Random idea: Maybe the linker tool needs a debug_output_path?
> > 
> > As an additional parameter? Currenty linker seems to be invoked through
> > shared_library / executable targets, and it seems that I need to patch GN in
> > order to add debug_output_path to them.
> 
> Yes, I think this may require a change to GN because the
> shared_library/executable/other linker tool types don't place their outputs in
> the bundle directly, they go into places like
> "obj/chrome/chrome_helper_app_executable/Google Chrome Helper". At that time,
> the linker target doesn't know where in the bundle the file ultimately will
end
> up, so it does seem like it will require passing more information to the
linker
> tool().
> 
> I don't really have a clear path to fixing this laid out -- it's going to take
> some fiddling to figure out the best solution.

I updated a couple of Yandex-specific scripts that relied on old .dSYM names
(had to be done because we have a ton of builds where the tools should work).
Most likely won't have enough time to tackle the GN work.