Right now, if you use use_frameworks!
in your Podfile, CocoaPods
generate configuration for release:
//:configuration = Release
SWIFT_OPTIMIZATION_LEVEL = -O
Since Swift compiler can do more with (-Owholemodule) see here I think it is better to set this optimization as default and allow to tune it from podfile somehow.
For instance, with block syntax:
pod 'name', 'version' do |configuration|
configuration.Debug.SWIFT_OPTIMIZATION_LEVEL = '-Onone'
configuration.Release.SWIFT_OPTIMIZATION_LEVEL = '-Owholemodule'
end
Or use keys with configuration.
prefix. For example:
pod 'name', 'version',
'configuration.Debug.SWIFT_OPTIMIZATION_LEVEL' => '-Onone',
'configuration.Release.SWIFT_OPTIMIZATION_LEVEL' => '-Owholemodule'
Or with configuration Key
pod 'name', 'version', configuration: {
'Debug.SWIFT_OPTIMIZATION_LEVEL' => '-Onone',
'Release.SWIFT_OPTIMIZATION_LEVEL' => '-Owholemodule'
}
You can do this in the post install hook. We just use the Xcode default value.
@segiddins Does this mean that Pods never build with optimization unless I setup a post install hook? If so, that could explain the compiler crash I'm seeing when building my project with whole module optimization where the compiler crashes because a function definition from a pod doesn't match the call site expectation.
Or if the pod specifies it in its pod_target_xcconfig. But that shouldn't in itself cause a crash, though swiftc sometimes crashes in optimization passes.
I was able to add this to my post_install
script like this:
if config.name == 'Release'
config.build_settings['SWIFT_OPTIMIZATION_LEVEL'] = '-Owholemodule'
else
config.build_settings['SWIFT_OPTIMIZATION_LEVEL'] = '-Onone'
end
I also noticed that the Test
configuration I had setup had defaulted to -O
, which is bad. It was a duplicate of the Debug
configuration, but I'm guessing that CocoaPods only uses the debug settings the Debug
configuration. @segiddins ? It seems like it might be better to match some of the Pods project optimization settings with the main target project. Otherwise everyone will have to use a post_install
script to change settings.
I think it is correct that we use Xcode defaults for generating the Pods project.
+1 on sticking to Xcode's defaults. This is a perfect case for a plugin BTW :+1:
Here is the plugin created by Jed Lewison.
This still seems to be an issue.
In Xcode 8 -whole-module-optimization
became the default for new projects (https://swift.org/blog/whole-module-optimizations/).
If I create a new project, the app target indeed uses that. However, if I add a simple CocoaPods integration and run pod install
, the pod target still uses single file optimization.
Podfile:
target 'Test' do
use_frameworks!
pod 'Alamofire', '~> 3.0'
end
This was tested using CocoaPods v1.2.0 with Xcode 8.2.1
@segiddins Shall I create a new issue, or do you want to reopen this one?
A PR regenerating the defaults is probably necessary, I don't think anyone has done that for the past few Xcode releases
@segiddins It was my understanding that CocoaPods would/should get the Xcode default values (e.g. for optimization level) dynamically. But if I get what you're saying: CocoaPods basically has some default values hardcoded, which for the Swift optimization level should be equal to the Xcode default?
As we see now, it's very easy for those hardcoded defaults to get out of sync with Xcode's defaults.
Is there any way the Xcode defaults could be grabbed dynamically?
They can't be -- it's a manual process to generate the defaults
Ok, understood, thank you.
Xcodeproj -- via rake common_build_settings:rebuild
@segiddins Updated with Xcode 8.2.1: https://github.com/CocoaPods/Xcodeproj/pull/468
Here is a complete post_install
script I added to my Podfile
based on the comment above by @jshier
post_install do |installer|
installer.pods_project.build_configurations.each do |config|
if config.name == 'Release'
config.build_settings['SWIFT_OPTIMIZATION_LEVEL'] = '-Owholemodule'
else
config.build_settings['SWIFT_OPTIMIZATION_LEVEL'] = '-Onone'
end
end
end
There might be some additional settings we need that are new in Xcode 9.3. There's a more recent issue that's tracking adding these defaults in 1.4.1 or 1.5.0.
@jshier we did update them with Xcode 9.3 https://github.com/CocoaPods/Xcodeproj/pull/541
@jshier @dnkoutso Looking more closely I believe the problem is related to when you include one or more Objective-C only pods. Each Swift target is getting the (target level) build setting to enable whole module optimization. But each Objective-C only target is not. In this case Xcode seems to warn / prompt you to enable the "whole module optimization" at the project level.
Steps to reproduce:
1- create a new project
2- create a Podfile
3- add pod "Result" (a swift only pod) and observe that the Result target has whole module optimization enabled and Xcode does not complain.
4- add pod "Amplitude-iOS" (an Objective-C only pod) and observe that the target does not have a whole module optimization setting at the target level and Xcode warns the user and prompts to enable whole module optimization at the project level.
My script above sets the build setting at the project level and Xcode is happy.
Want me to file a new bug for this?
@mpvosseller have you tried using the latest xcodeproj master version? Does it still exhibit these warnings?
@dnkoutso I just tried the master branch of xcodeproj and yea, it appears to fix this issue. Thanks!
Latest version of CocoaPods fixes the issue. Thank you.
@mpvosseller ,
In my case -Owholemodule
in release mode is crashing(Only for one pod) . Can I set to -Onone
for only particular pod?
So every time I release app I have tu update my project to recommended settings or I have to add some script to do it after pod install ? This is how it should work with cocoa-pods right now to get optimizations for release build ? Interesting ,ok now I read in comments it is fixed but I have updated cocoapods to 1.5.3 and still get this so maybe its not released ? ... ok... will wait few months more to see
Still happening on 1.5.3 cocoapods if I mix objc and swift pods.
For the record, this isn't fixed in 1.5.3, but it does appear to be fixed in the latest beta (1.6.0)
Most helpful comment
I was able to add this to my
post_install
script like this:I also noticed that the
Test
configuration I had setup had defaulted to-O
, which is bad. It was a duplicate of theDebug
configuration, but I'm guessing that CocoaPods only uses the debug settings theDebug
configuration. @segiddins ? It seems like it might be better to match some of the Pods project optimization settings with the main target project. Otherwise everyone will have to use apost_install
script to change settings.