Reland of Do not produce dSYM file for the iOS Frameworks with bitcode

Reland of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset #1 id:1 of https://codereview.webrtc.org/2719773002/ )

Reason for revert:
Fixing issues with the framework builder.

Original issue's description:
> Revert of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset #2 id:20001 of https://codereview.webrtc.org/2705163007/ )
> 
> Reason for revert:
> Looks like this caused the iOS API Framework Builder to fail.
> 
> https://build.chromium.org/p/client.webrtc/builders/iOS%20API%20Framework%20Builder/builds/3487/steps/zip%20archive/logs/stdio
> 
> Zipping /b/rr/tmpkIyP1e/w/webrtc_ios_api_framework.zip...
> Traceback (most recent call last):
>   File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 144, in <module>
>     sys.exit(main())
>   File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 130, in main
>     exit_code = zip_with_subprocess(root, output, entries)
>   File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 43, in zip_with_subprocess
>     assert os.path.isdir(path), path
> AssertionError: /b/c/b/iOS_API_Framework_Builder/src/out_ios_libs/WebRTC.dSYM/
> step returned non-zero exit code: 1
> @@@STEP_FAILURE@@@
> 
> Original issue's description:
> > Do not produce dSYM file for the iOS Frameworks with bitcode
> > 
> > Though dSYM files can be generated when building applications or libraries
> > with bitcode. They cannot be used to symbolicate crash reports from
> > applications. Instead, developers need to grab the real dSYM files, which
> > are generated for each specific device type after uploading an iOS / tvOS
> > application to App Store (or to a device using Xcode). Apple clearly warns
> > about it in its documentation:
> > 
> > https://developer.apple.com/library/content/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATION-BITCODE
> > 
> > With that in mind, I believe that it would be better to not confuse
> > developers by giving them dSYM files that are not very helpful with
> > the bitcode-enabled framework. Thus, proposing the following modification
> > to the building script, to generate dSYM by default only without
> > the bitcode option. However, if some developers still want to get
> > the dSYM files as a build-process artifact, when enabling bitcode,
> > they can explicitly add --extra-gn-args enable_dsyms=true to the script.
> > 
> > Let me know if it lgty.
> > 
> > NOTRY=True
> > BUG=None
> > 
> > Review-Url: https://codereview.webrtc.org/2705163007
> > Cr-Commit-Position: refs/heads/master@{#16836}
> > Committed: https://chromium.googlesource.com/external/webrtc/+/d74517c52a6cd4172b1f3fdc4e624b6145ff5a0f
> 
> TBR=kjellander@webrtc.org,kthelgason@webrtc.org,VladimirTechMan@gmail.com
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=None
> NOTRY=True
> 
> Review-Url: https://codereview.webrtc.org/2719773002
> Cr-Commit-Position: refs/heads/master@{#16844}
> Committed: https://chromium.googlesource.com/external/webrtc/+/da00077cfac335503b3335d5eac110f2f5bff408

TBR=kjellander@webrtc.org,vladimirtechman@gmail.com,tommi@webrtc.org
NOTRY=true
BUG=None

Review-Url: https://codereview.webrtc.org/2718983002
Cr-Commit-Position: refs/heads/master@{#16924}
Committed: https://chromium.googlesource.com/external/webrtc/+/28922448012e39f33124bb112e54faecc454dea6

[kthelgason, 2017-02-27 07:30:14]

Created Reland of Do not produce dSYM file for the iOS Frameworks with bitcode

[kthelgason, 2017-02-27 07:32:51]

kjellander@ can you take a look at the build failure and advise Vladimir of what
to fix, or alternatively fix it yourself if it's a small fix?

[tommi, 2017-02-27 08:49:20]

rs lgtm

[kjellander_webrtc, 2017-02-27 23:48:52]

Can you have PS#1 be the pristine revert of the revert and PS#2 contain the
actual fixed version, so I can tell what is the difference?

[VladimirTechMan, 2017-02-28 01:53:25]

On 2017/02/27 23:48:52, kjellander_webrtc wrote:
> Can you have PS#1 be the pristine revert of the revert and PS#2 contain the
> actual fixed version, so I can tell what is the difference?

Henrik, I was not sure if your request above was primarily for me, or for your
colleagues (or just all three of us). As for the failure that happened with the
iOS builder – which I am sorry about – the reason of it is very understandable,
after I quickly looked at it today.

Last year, the ios_api_framework.py script has been modified to always add the
WebRTC.dSYM dir into the zip archive. Here is the related issue:

https://codereview.chromium.org/2472473004/

Earlier this year, I have introduced the changes in the Chromium and WebRTC
repositories, to support the option for building iOS frameworks (or static libs)
with bitcode. After those fixes landed in the master branches, there was a
change to the ios_api_framework.py script, to build using bitcode. (I somehow
missed that one and was not aware of it, actually, till this situation happened
over the weekend.) Here is the review for that specific change:

https://chromium-review.googlesource.com/c/433757/

As the logic in ios_api_framework.py was implemented to unconditionally expect
the dSYM files after building an iOS framework, it was broken by my changes
above – by not providing dSYM files when bitcode is enabled.

Considering ios_api_framework.py itself, three solutions are possible, depending
on the goals that you have in mind for that zip archive and the dSYM file being
added to it:
(1) Do not enable the bitcode option inside ios_api_framework.py. And then
archive the real dSYM file matching the complied framework.
(2) Do build with the bitcode option, but do not expect the dSYM file as a
result from the build_ios_libs.py script. As per my description above.
(3) Do build with the bitcode option, and explicitly add "enable_dsyms=true" to
the "--extra-gn-args" part when calling build_ios_libs.py, to force the
generation of the dSYM files, even though they are not useful practically to
debug bitcode-enabled frameworks.

I hope that helps. Let me know what your thoughts are.

[kthelgason, 2017-02-28 09:34:09]

On 2017/02/28 01:53:25, VladimirTechMan wrote:
> On 2017/02/27 23:48:52, kjellander_webrtc wrote:
> > Can you have PS#1 be the pristine revert of the revert and PS#2 contain the
> > actual fixed version, so I can tell what is the difference?
> 
> Henrik, I was not sure if your request above was primarily for me, or for your
> colleagues (or just all three of us). As for the failure that happened with
the
> iOS builder – which I am sorry about – the reason of it is very
understandable,
> after I quickly looked at it today.

PS1 is just the original CL, nothing has been added so far.

> Considering ios_api_framework.py itself, three solutions are possible,
depending
> on the goals that you have in mind for that zip archive and the dSYM file
being
> added to it:
> (1) Do not enable the bitcode option inside ios_api_framework.py. And then
> archive the real dSYM file matching the complied framework.
> (2) Do build with the bitcode option, but do not expect the dSYM file as a
> result from the build_ios_libs.py script. As per my description above.
> (3) Do build with the bitcode option, and explicitly add "enable_dsyms=true"
to
> the "--extra-gn-args" part when calling build_ios_libs.py, to force the
> generation of the dSYM files, even though they are not useful practically to
> debug bitcode-enabled frameworks.
> 
> I hope that helps. Let me know what your thoughts are.

Thanks for the thorough explanation. I'd prefer to go with option 2 here, as I
see
no point in shipping the dSYM's if they can't be used to symbolicate properly. 

What do you think Henrik?

[kjellander_webrtc, 2017-02-28 22:59:05]

On 2017/02/28 09:34:09, kthelgason wrote:
> On 2017/02/28 01:53:25, VladimirTechMan wrote:
> > On 2017/02/27 23:48:52, kjellander_webrtc wrote:
> > > Can you have PS#1 be the pristine revert of the revert and PS#2 contain
the
> > > actual fixed version, so I can tell what is the difference?
> > 
> > Henrik, I was not sure if your request above was primarily for me, or for
your
> > colleagues (or just all three of us). As for the failure that happened with
> the
> > iOS builder – which I am sorry about – the reason of it is very
> understandable,
> > after I quickly looked at it today.
> 
> PS1 is just the original CL, nothing has been added so far.
> 
> > Considering ios_api_framework.py itself, three solutions are possible,
> depending
> > on the goals that you have in mind for that zip archive and the dSYM file
> being
> > added to it:
> > (1) Do not enable the bitcode option inside ios_api_framework.py. And then
> > archive the real dSYM file matching the complied framework.
> > (2) Do build with the bitcode option, but do not expect the dSYM file as a
> > result from the build_ios_libs.py script. As per my description above.
> > (3) Do build with the bitcode option, and explicitly add "enable_dsyms=true"
> to
> > the "--extra-gn-args" part when calling build_ios_libs.py, to force the
> > generation of the dSYM files, even though they are not useful practically to
> > debug bitcode-enabled frameworks.
> > 
> > I hope that helps. Let me know what your thoughts are.
> 
> Thanks for the thorough explanation. I'd prefer to go with option 2 here, as I
> see
> no point in shipping the dSYM's if they can't be used to symbolicate properly.

> 
> What do you think Henrik?

Right, so this was a problem with the buildbot logic expecting that directory to
be present. We would have caught this upfront if we would have just run the
ios_api_framework bot, which we should always do for changes like this.
I'm removing the packaging of the dir in
https://chromium-review.googlesource.com/c/448024/ so I'll fire a tryjob here
once that's landed.

[kjellander_webrtc, 2017-02-28 23:08:31]

Description was changed from

==========
Reland of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset
#1 id:1 of https://codereview.webrtc.org/2719773002/ )

Reason for revert:
Fixing issues with the framework builder.

Original issue's description:
> Revert of Do not produce dSYM file for the iOS Frameworks with bitcode
(patchset #2 id:20001 of https://codereview.webrtc.org/2705163007/ )
> 
> Reason for revert:
> Looks like this caused the iOS API Framework Builder to fail.
> 
>
https://build.chromium.org/p/client.webrtc/builders/iOS%20API%20Framework%20B...
> 
> Zipping /b/rr/tmpkIyP1e/w/webrtc_ios_api_framework.zip...
> Traceback (most recent call last):
>   File
"/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py",
line 144, in <module>
>     sys.exit(main())
>   File
"/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py",
line 130, in main
>     exit_code = zip_with_subprocess(root, output, entries)
>   File
"/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py",
line 43, in zip_with_subprocess
>     assert os.path.isdir(path), path
> AssertionError: /b/c/b/iOS_API_Framework_Builder/src/out_ios_libs/WebRTC.dSYM/
> step returned non-zero exit code: 1
> @@@STEP_FAILURE@@@
> 
> Original issue's description:
> > Do not produce dSYM file for the iOS Frameworks with bitcode
> > 
> > Though dSYM files can be generated when building applications or libraries
> > with bitcode. They cannot be used to symbolicate crash reports from
> > applications. Instead, developers need to grab the real dSYM files, which
> > are generated for each specific device type after uploading an iOS / tvOS
> > application to App Store (or to a device using Xcode). Apple clearly warns
> > about it in its documentation:
> > 
> >
https://developer.apple.com/library/content/technotes/tn2151/_index.html#//ap...
> > 
> > With that in mind, I believe that it would be better to not confuse
> > developers by giving them dSYM files that are not very helpful with
> > the bitcode-enabled framework. Thus, proposing the following modification
> > to the building script, to generate dSYM by default only without
> > the bitcode option. However, if some developers still want to get
> > the dSYM files as a build-process artifact, when enabling bitcode,
> > they can explicitly add --extra-gn-args enable_dsyms=true to the script.
> > 
> > Let me know if it lgty.
> > 
> > NOTRY=True
> > BUG=None
> > 
> > Review-Url: https://codereview.webrtc.org/2705163007
> > Cr-Commit-Position: refs/heads/master@{#16836}
> > Committed:
https://chromium.googlesource.com/external/webrtc/+/d74517c52a6cd4172b1f3fdc4...
> 
> TBR=kjellander@webrtc.org,kthelgason@webrtc.org,VladimirTechMan@gmail.com
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=None
> NOTRY=True
> 
> Review-Url: https://codereview.webrtc.org/2719773002
> Cr-Commit-Position: refs/heads/master@{#16844}
> Committed:
https://chromium.googlesource.com/external/webrtc/+/da00077cfac335503b3335d5e...

TBR=kjellander@webrtc.org,vladimirtechman@gmail.com,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=None
==========

to

==========
Reland of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset
#1 id:1 of https://codereview.webrtc.org/2719773002/ )

Reason for revert:
Fixing issues with the framework builder.

Original issue's description:
> Revert of Do not produce dSYM file for the iOS Frameworks with bitcode
(patchset #2 id:20001 of https://codereview.webrtc.org/2705163007/ )
> 
> Reason for revert:
> Looks like this caused the iOS API Framework Builder to fail.
> 
>
https://build.chromium.org/p/client.webrtc/builders/iOS%20API%20Framework%20B...
> 
> Zipping /b/rr/tmpkIyP1e/w/webrtc_ios_api_framework.zip...
> Traceback (most recent call last):
>   File
"/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py",
line 144, in <module>
>     sys.exit(main())
>   File
"/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py",
line 130, in main
>     exit_code = zip_with_subprocess(root, output, entries)
>   File
"/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py",
line 43, in zip_with_subprocess
>     assert os.path.isdir(path), path
> AssertionError: /b/c/b/iOS_API_Framework_Builder/src/out_ios_libs/WebRTC.dSYM/
> step returned non-zero exit code: 1
> @@@STEP_FAILURE@@@
> 
> Original issue's description:
> > Do not produce dSYM file for the iOS Frameworks with bitcode
> > 
> > Though dSYM files can be generated when building applications or libraries
> > with bitcode. They cannot be used to symbolicate crash reports from
> > applications. Instead, developers need to grab the real dSYM files, which
> > are generated for each specific device type after uploading an iOS / tvOS
> > application to App Store (or to a device using Xcode). Apple clearly warns
> > about it in its documentation:
> > 
> >
https://developer.apple.com/library/content/technotes/tn2151/_index.html#//ap...
> > 
> > With that in mind, I believe that it would be better to not confuse
> > developers by giving them dSYM files that are not very helpful with
> > the bitcode-enabled framework. Thus, proposing the following modification
> > to the building script, to generate dSYM by default only without
> > the bitcode option. However, if some developers still want to get
> > the dSYM files as a build-process artifact, when enabling bitcode,
> > they can explicitly add --extra-gn-args enable_dsyms=true to the script.
> > 
> > Let me know if it lgty.
> > 
> > NOTRY=True
> > BUG=None
> > 
> > Review-Url: https://codereview.webrtc.org/2705163007
> > Cr-Commit-Position: refs/heads/master@{#16836}
> > Committed:
https://chromium.googlesource.com/external/webrtc/+/d74517c52a6cd4172b1f3fdc4...
> 
> TBR=kjellander@webrtc.org,kthelgason@webrtc.org,VladimirTechMan@gmail.com
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=None
> NOTRY=True
> 
> Review-Url: https://codereview.webrtc.org/2719773002
> Cr-Commit-Position: refs/heads/master@{#16844}
> Committed:
https://chromium.googlesource.com/external/webrtc/+/da00077cfac335503b3335d5e...

TBR=kjellander@webrtc.org,vladimirtechman@gmail.com,tommi@webrtc.org
NOTRY=true
BUG=None
==========

[VladimirTechMan, 2017-02-28 23:22:00]

On 2017/02/28 22:59:05, kjellander_webrtc wrote:
...
> 
> Right, so this was a problem with the buildbot logic expecting that directory
to
> be present. We would have caught this upfront if we would have just run the
> ios_api_framework bot, which we should always do for changes like this.

I totally agree, Henrik. Mea culpa.

> I'm removing the packaging of the dir in
> https://chromium-review.googlesource.com/c/448024/ so I'll fire a tryjob here
> once that's landed.

I am wondering why would not we make that part of the building bot a little more
universal and less fragile, on any possible future changes related to the dSYM
directory? Something like:

dsym_output_dir = output_dir.join('WebRTC.dSYM')
if os.path.isdir(dsym_output_dir):
  pkg.add_directory(dsym_output_dir)

(well, depending on what API to check the presence of file / directory is
available inside that script).

[kjellander_webrtc, 2017-02-28 23:30:32]

The CQ bit was checked by kjellander@webrtc.org

[commit-bot: I haz the power, 2017-02-28 23:30:37]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2017-02-28 23:33:26]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1488324632976840, "parent_rev":
"93a26f6bb8015f0f3d6d5a1faa3287b086a7f94f", "commit_rev":
"28922448012e39f33124bb112e54faecc454dea6"}

[commit-bot: I haz the power, 2017-02-28 23:33:29]

Description was changed from

==========
Reland of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset
#1 id:1 of https://codereview.webrtc.org/2719773002/ )

Reason for revert:
Fixing issues with the framework builder.

Original issue's description:
> Revert of Do not produce dSYM file for the iOS Frameworks with bitcode
(patchset #2 id:20001 of https://codereview.webrtc.org/2705163007/ )
> 
> Reason for revert:
> Looks like this caused the iOS API Framework Builder to fail.
> 
>
https://build.chromium.org/p/client.webrtc/builders/iOS%20API%20Framework%20B...
> 
> Zipping /b/rr/tmpkIyP1e/w/webrtc_ios_api_framework.zip...
> Traceback (most recent call last):
>   File
"/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py",
line 144, in <module>
>     sys.exit(main())
>   File
"/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py",
line 130, in main
>     exit_code = zip_with_subprocess(root, output, entries)
>   File
"/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py",
line 43, in zip_with_subprocess
>     assert os.path.isdir(path), path
> AssertionError: /b/c/b/iOS_API_Framework_Builder/src/out_ios_libs/WebRTC.dSYM/
> step returned non-zero exit code: 1
> @@@STEP_FAILURE@@@
> 
> Original issue's description:
> > Do not produce dSYM file for the iOS Frameworks with bitcode
> > 
> > Though dSYM files can be generated when building applications or libraries
> > with bitcode. They cannot be used to symbolicate crash reports from
> > applications. Instead, developers need to grab the real dSYM files, which
> > are generated for each specific device type after uploading an iOS / tvOS
> > application to App Store (or to a device using Xcode). Apple clearly warns
> > about it in its documentation:
> > 
> >
https://developer.apple.com/library/content/technotes/tn2151/_index.html#//ap...
> > 
> > With that in mind, I believe that it would be better to not confuse
> > developers by giving them dSYM files that are not very helpful with
> > the bitcode-enabled framework. Thus, proposing the following modification
> > to the building script, to generate dSYM by default only without
> > the bitcode option. However, if some developers still want to get
> > the dSYM files as a build-process artifact, when enabling bitcode,
> > they can explicitly add --extra-gn-args enable_dsyms=true to the script.
> > 
> > Let me know if it lgty.
> > 
> > NOTRY=True
> > BUG=None
> > 
> > Review-Url: https://codereview.webrtc.org/2705163007
> > Cr-Commit-Position: refs/heads/master@{#16836}
> > Committed:
https://chromium.googlesource.com/external/webrtc/+/d74517c52a6cd4172b1f3fdc4...
> 
> TBR=kjellander@webrtc.org,kthelgason@webrtc.org,VladimirTechMan@gmail.com
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=None
> NOTRY=True
> 
> Review-Url: https://codereview.webrtc.org/2719773002
> Cr-Commit-Position: refs/heads/master@{#16844}
> Committed:
https://chromium.googlesource.com/external/webrtc/+/da00077cfac335503b3335d5e...

TBR=kjellander@webrtc.org,vladimirtechman@gmail.com,tommi@webrtc.org
NOTRY=true
BUG=None
==========

to

==========
Reland of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset
#1 id:1 of https://codereview.webrtc.org/2719773002/ )

Reason for revert:
Fixing issues with the framework builder.

Original issue's description:
> Revert of Do not produce dSYM file for the iOS Frameworks with bitcode
(patchset #2 id:20001 of https://codereview.webrtc.org/2705163007/ )
> 
> Reason for revert:
> Looks like this caused the iOS API Framework Builder to fail.
> 
>
https://build.chromium.org/p/client.webrtc/builders/iOS%20API%20Framework%20B...
> 
> Zipping /b/rr/tmpkIyP1e/w/webrtc_ios_api_framework.zip...
> Traceback (most recent call last):
>   File
"/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py",
line 144, in <module>
>     sys.exit(main())
>   File
"/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py",
line 130, in main
>     exit_code = zip_with_subprocess(root, output, entries)
>   File
"/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py",
line 43, in zip_with_subprocess
>     assert os.path.isdir(path), path
> AssertionError: /b/c/b/iOS_API_Framework_Builder/src/out_ios_libs/WebRTC.dSYM/
> step returned non-zero exit code: 1
> @@@STEP_FAILURE@@@
> 
> Original issue's description:
> > Do not produce dSYM file for the iOS Frameworks with bitcode
> > 
> > Though dSYM files can be generated when building applications or libraries
> > with bitcode. They cannot be used to symbolicate crash reports from
> > applications. Instead, developers need to grab the real dSYM files, which
> > are generated for each specific device type after uploading an iOS / tvOS
> > application to App Store (or to a device using Xcode). Apple clearly warns
> > about it in its documentation:
> > 
> >
https://developer.apple.com/library/content/technotes/tn2151/_index.html#//ap...
> > 
> > With that in mind, I believe that it would be better to not confuse
> > developers by giving them dSYM files that are not very helpful with
> > the bitcode-enabled framework. Thus, proposing the following modification
> > to the building script, to generate dSYM by default only without
> > the bitcode option. However, if some developers still want to get
> > the dSYM files as a build-process artifact, when enabling bitcode,
> > they can explicitly add --extra-gn-args enable_dsyms=true to the script.
> > 
> > Let me know if it lgty.
> > 
> > NOTRY=True
> > BUG=None
> > 
> > Review-Url: https://codereview.webrtc.org/2705163007
> > Cr-Commit-Position: refs/heads/master@{#16836}
> > Committed:
https://chromium.googlesource.com/external/webrtc/+/d74517c52a6cd4172b1f3fdc4...
> 
> TBR=kjellander@webrtc.org,kthelgason@webrtc.org,VladimirTechMan@gmail.com
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=None
> NOTRY=True
> 
> Review-Url: https://codereview.webrtc.org/2719773002
> Cr-Commit-Position: refs/heads/master@{#16844}
> Committed:
https://chromium.googlesource.com/external/webrtc/+/da00077cfac335503b3335d5e...

TBR=kjellander@webrtc.org,vladimirtechman@gmail.com,tommi@webrtc.org
NOTRY=true
BUG=None

Review-Url: https://codereview.webrtc.org/2718983002
Cr-Commit-Position: refs/heads/master@{#16924}
Committed:
https://chromium.googlesource.com/external/webrtc/+/28922448012e39f33124bb112...
==========

[commit-bot: I haz the power, 2017-02-28 23:33:31]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/external/webrtc/+/28922448012e39f33124bb112...

[kjellander_webrtc, 2017-02-28 23:50:15]

On 2017/02/28 23:22:00, VladimirTechMan wrote:
> On 2017/02/28 22:59:05, kjellander_webrtc wrote:
> ...
> > 
> > Right, so this was a problem with the buildbot logic expecting that
directory
> to
> > be present. We would have caught this upfront if we would have just run the
> > ios_api_framework bot, which we should always do for changes like this.
> 
> I totally agree, Henrik. Mea culpa.
> 
> > I'm removing the packaging of the dir in
> > https://chromium-review.googlesource.com/c/448024/ so I'll fire a tryjob
here
> > once that's landed.
> 
> I am wondering why would not we make that part of the building bot a little
more
> universal and less fragile, on any possible future changes related to the dSYM
> directory? Something like:
> 
> dsym_output_dir = output_dir.join('WebRTC.dSYM')
> if os.path.isdir(dsym_output_dir):
>   pkg.add_directory(dsym_output_dir)
> 
> (well, depending on what API to check the presence of file / directory is
> available inside that script).

You're right. I think it would be even better if we just zipped everything in a
single directory, so if we could change the script to that instead we wouldn't
need to have this fragile add-each-item-individually logic on the buildbot side.
I guess it was just that we wanted the zip layout to be of a specific kind (i.e.
no sub-dir) and that not all that was built actually was going to be included.
Best would be if this script handled the packaging instead of the buildbot step.
Then it could just upload the file directly.