Support building libs and apps for iOS, watchOS, and tvOS with bitcode

Support building libs and apps for iOS, watchOS, and tvOS with bitcode

This patch adds flag "enable_ios_bitcode" to the build configuration
for iOS applications, frameworks, and libraries. It triggers adding
the "-fembed-bitcode" option when compiling and linking parts of the
projects for production builds (is_debug = false), and it triggers
adding the "-fembed-bitcode-marker" option in the case of debug builds.
That is along the lines of how Xcode does it, since the introduction
of the bitcode support and corresponding options.

The option only makes sense for Xcode build tools now and for iOS SDK
compatible builds (iOS, watchOS, tvOS). Thus, it the options is only
applicable when building for iOS with use_xcode_clang = true. And only
when building for real devices (with ARM CPUs). The latter limitation
is due to the usage of Intel assembly syntax and the Yasm tool when
building for iOS simulator (Yasm cannot emit bitcode sections now).
But it does not affect the workflow for the generated applications,
frameworks and libraries at the moment of submitting this patch:
For now, Xcode only cares about the availability of bitcode sections
in _all_ the pre-compiled parts of bitcode-enabled projects when
building those projects for ARM-based devices. Building for iOS
simulator, it handles the projects just fine, with or without bitcode
sections available in the linked libraries. That may change in the
future, of course, but currently it should be fine.

BUG=680711
Review-Url: https://codereview.chromium.org/2631573002
Cr-Commit-Position: refs/heads/master@{#443535}
Committed: https://chromium.googlesource.com/chromium/src/+/0e1f16653bdf3cacd121bfbc1f32b25f01ac6aed

[VladimirTechMan, 2017-01-12 22:36:03]

Description was changed from

==========
Support building libs and apps for iOS, watchOS, and tvOS with bitcode

This patch adds flag "enable_ios_bitcode" to the build configuration
for iOS applications, frameworks, and libraries. It triggers adding
the "-fembed-bitcode" option when compiling and linking parts of the
projects for production builds (is_debug = false), and it triggers
adding the "-fembed-bitcode-marker" option in the case of debug builds.
That is along the lines of how Xcode does it, since the introduction
of the bitcode support and corresponding options.

The option only makes sense for Xcode build tools now and for iOS SDK
compatible builds (iOS, watchOS, tvOS). Thus, it the options is only
applicable when building for iOS with use_xcode_clang = true. And only
when building for real devices (with ARM CPUs). The latter limitation
is due to the usage of Intel assembly syntax and the Yasm tool when
building for iOS simulator (Yasm cannot emit bitcode sections now).
But it does not affect the workflow for the generated applications,
frameworks and libraries at the moment of submitting this patch:
For now, Xcode only cares about the availability of bitcode sections
in _all_ the pre-compiled parts of bitcode-enabled projects when
building those projects for ARM-based devices. Building for iOS
simulator, it handles the projects just fine, with or without bitcode
sections available in the linked libraries. That may change in the
future, of course, but currently it should be fine.

BUG=680711
==========

to

==========
Support building libs and apps for iOS, watchOS, and tvOS with bitcode

This patch adds flag "enable_ios_bitcode" to the build configuration
for iOS applications, frameworks, and libraries. It triggers adding
the "-fembed-bitcode" option when compiling and linking parts of the
projects for production builds (is_debug = false), and it triggers
adding the "-fembed-bitcode-marker" option in the case of debug builds.
That is along the lines of how Xcode does it, since the introduction
of the bitcode support and corresponding options.

The option only makes sense for Xcode build tools now and for iOS SDK
compatible builds (iOS, watchOS, tvOS). Thus, it the options is only
applicable when building for iOS with use_xcode_clang = true. And only
when building for real devices (with ARM CPUs). The latter limitation
is due to the usage of Intel assembly syntax and the Yasm tool when
building for iOS simulator (Yasm cannot emit bitcode sections now).
But it does not affect the workflow for the generated applications,
frameworks and libraries at the moment of submitting this patch:
For now, Xcode only cares about the availability of bitcode sections
in _all_ the pre-compiled parts of bitcode-enabled projects when
building those projects for ARM-based devices. Building for iOS
simulator, it handles the projects just fine, with or without bitcode
sections available in the linked libraries. That may change in the
future, of course, but currently it should be fine.

BUG=680711
==========

[VladimirTechMan, 2017-01-12 22:36:03]

vladimirtechman@gmail.com changed reviewers:
+ rsesek@chromium.org, sdefresne@chromium.org

[sdefresne, 2017-01-13 08:48:41]

The CQ bit was checked by sdefresne@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-13 08:49:04]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-13 09:50:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-13 09:50:33]

Dry run: This issue passed the CQ dry run.

[sdefresne, 2017-01-13 10:09:35]

lgtm

https://codereview.chromium.org/2631573002/diff/1/build/config/ios/BUILD.gn
File build/config/ios/BUILD.gn (right):

https://codereview.chromium.org/2631573002/diff/1/build/config/ios/BUILD.gn#n...
build/config/ios/BUILD.gn:18: # NOTE: Currently this option is ignored when
building versions for
Is there plan to support bitcode for simulator builds (I read "currently" as
implying that at some point this will change)? Maybe remove "currently" if there
is no such plan.

[VladimirTechMan, 2017-01-13 10:25:29]

Updated the note about the flag in BUILD.gn following the comment from
@sdefresne. Let me know if that LGTY now.

[sdefresne, 2017-01-13 10:27:29]

still lgtm

[VladimirTechMan, 2017-01-13 10:31:27]

The CQ bit was checked by vladimirtechman@gmail.com

[commit-bot: I haz the power, 2017-01-13 10:32:19]

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

[commit-bot: I haz the power, 2017-01-13 12:15:48]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1484303487383890,
"parent_rev": "6947bf33fca57e328ba961b246cb1b386da6c706", "commit_rev":
"0e1f16653bdf3cacd121bfbc1f32b25f01ac6aed"}

[commit-bot: I haz the power, 2017-01-13 12:16:24]

Description was changed from

==========
Support building libs and apps for iOS, watchOS, and tvOS with bitcode

This patch adds flag "enable_ios_bitcode" to the build configuration
for iOS applications, frameworks, and libraries. It triggers adding
the "-fembed-bitcode" option when compiling and linking parts of the
projects for production builds (is_debug = false), and it triggers
adding the "-fembed-bitcode-marker" option in the case of debug builds.
That is along the lines of how Xcode does it, since the introduction
of the bitcode support and corresponding options.

The option only makes sense for Xcode build tools now and for iOS SDK
compatible builds (iOS, watchOS, tvOS). Thus, it the options is only
applicable when building for iOS with use_xcode_clang = true. And only
when building for real devices (with ARM CPUs). The latter limitation
is due to the usage of Intel assembly syntax and the Yasm tool when
building for iOS simulator (Yasm cannot emit bitcode sections now).
But it does not affect the workflow for the generated applications,
frameworks and libraries at the moment of submitting this patch:
For now, Xcode only cares about the availability of bitcode sections
in _all_ the pre-compiled parts of bitcode-enabled projects when
building those projects for ARM-based devices. Building for iOS
simulator, it handles the projects just fine, with or without bitcode
sections available in the linked libraries. That may change in the
future, of course, but currently it should be fine.

BUG=680711
==========

to

==========
Support building libs and apps for iOS, watchOS, and tvOS with bitcode

This patch adds flag "enable_ios_bitcode" to the build configuration
for iOS applications, frameworks, and libraries. It triggers adding
the "-fembed-bitcode" option when compiling and linking parts of the
projects for production builds (is_debug = false), and it triggers
adding the "-fembed-bitcode-marker" option in the case of debug builds.
That is along the lines of how Xcode does it, since the introduction
of the bitcode support and corresponding options.

The option only makes sense for Xcode build tools now and for iOS SDK
compatible builds (iOS, watchOS, tvOS). Thus, it the options is only
applicable when building for iOS with use_xcode_clang = true. And only
when building for real devices (with ARM CPUs). The latter limitation
is due to the usage of Intel assembly syntax and the Yasm tool when
building for iOS simulator (Yasm cannot emit bitcode sections now).
But it does not affect the workflow for the generated applications,
frameworks and libraries at the moment of submitting this patch:
For now, Xcode only cares about the availability of bitcode sections
in _all_ the pre-compiled parts of bitcode-enabled projects when
building those projects for ARM-based devices. Building for iOS
simulator, it handles the projects just fine, with or without bitcode
sections available in the linked libraries. That may change in the
future, of course, but currently it should be fine.

BUG=680711

Review-Url: https://codereview.chromium.org/2631573002
Cr-Commit-Position: refs/heads/master@{#443535}
Committed:
https://chromium.googlesource.com/chromium/src/+/0e1f16653bdf3cacd121bfbc1f32...
==========

[commit-bot: I haz the power, 2017-01-13 12:16:25]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/0e1f16653bdf3cacd121bfbc1f32...

[tk1061178_gmail.com, 2017-02-23 03:18:55]

 

I have got a problem

Using the bitcode to generate the framework such as Cronet.framework 
results in that the size of Cronet from 5.5M to 629M, it is too big. if we 
have some method to optimize the size with the bitcode？

在 2017年1月13日星期五 UTC+8下午6:27:31，sdef...@chromium.org写道：
>
> still lgtm
>
> https://codereview.chromium.org/2631573002/
>

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

[VladimirTechMan, 2017-02-27 03:47:07]

On 2017/02/23 03:18:55, tk1061178_gmail.com wrote:
>  
> 
> I have got a problem
> 
> Using the bitcode to generate the framework such as Cronet.framework 
> results in that the size of Cronet from 5.5M to 629M, it is too big. if we 
> have some method to optimize the size with the bitcode？
> 
> 在 2017年1月13日星期五 UTC+8下午6:27:31，sdef...@chromium.org写道：
> >
> > still lgtm
> >
> > https://codereview.chromium.org/2631573002/
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Chromium-reviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

The size of bitcode-enabled libraries is a known trade-off for the optimization
they allow doing before the complied application (not the initial bitcode
representation of it) is loaded on the device from App Store (or from Xcode in
the case of a developer's environment). You may also refer to comments 26 and 27
at the following link, discussing the same topic:

https://bugs.chromium.org/p/webrtc/issues/detail?id=5085#c26