Cocoapods: Pods project doesn't inherit settings for custom build configurations

[jshier]

• [x] I've read and understood the *CONTRIBUTING guidelines and have done my best effort to follow.

Report

What did you do?

Installed pods with a custom build configuration in my project.

What did you expect to happen?

My project's build configurations and their settings should be reflected exactly (minus pod specific settings for each pod target) in the Pods project. This ensure that optimization settings, build parameter, and other flags match, which have been issues before.

What happened instead?

Pods project apparently sets one set of default values for the Debug configuration (and in fact, always has a Debug configuration, even when I rename my project's Debug configuration to NewDebug), and a different set which are applied for all non-Debug configurations.

This forced Debug configuration that isn't reflected in the main project is perhaps the strangest thing here.

CocoaPods Environment

Stack

   CocoaPods : 1.5.2
        Ruby : ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin17]
    RubyGems : 2.7.6
        Host : Mac OS X 10.13.4 (17E202)
       Xcode : 9.3.1 (9E501)
         Git : git version 2.15.1 (Apple Git-101)
Ruby lib dir : /Users/jshier/.rvm/rubies/ruby-2.5.1/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ 79f90ff6d81518dc3bacb837ff053946a6d1bf0b

Installation Source

Executable Path: /Users/jshier/.rvm/gems/ruby-2.5.1@buildsettingsshouldmatch/bin/pod

Plugins

cocoapods-deintegrate : 1.0.2
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.0.0
cocoapods-trunk       : 1.3.0
cocoapods-try         : 1.1.0

Podfile

platform :ios, '11.0'

target 'BuildSettingsShouldMatch' do
  use_frameworks!

  pod 'Alamofire'
end

Project that demonstrates the issue

https://github.com/jshier/BuildSettingsShouldMatch

[dnkoutso]

Did not try the sample yet (but will) but making sure this is not missing:

platform :ios, '11.0'

project 'BuildSettingsShouldMatch', 'NewDebug' => :debug

target 'BuildSettingsShouldMatch' do
  use_frameworks!

  pod 'Alamofire'
end

I think the default Debug is actually added by Xcode for a new project once generated.

[dnkoutso]

@jshier did you get a chance to try the above?

[jshier]

Sorry, didn't realize you wanted me to try that. It may have made the LLVM optimization level match my OtherDebug optimization level, but it didn't affect my Swift optimization or compilation mode settings. All of those still match the release mode settings.

[dnkoutso]

interesting, thanks will double check it myself and see if we can fix this.

Sorry I should have been explicit.

[dnkoutso]

@jshier from digging at the code there is nothing that transfers over these values. The reason why SWIFT_OPTIMIZATION_LEVEL is because its the default setting set from Xcodeproj gem (see here https://github.com/CocoaPods/Xcodeproj/blob/master/lib/xcodeproj/constants.rb#L225-L231)

By adding 'NewDebug' => :debug it basically instructs pods to create a new build configuration and then it uses the default values.

There is a tiny bit of customization with regards to setting a few CocoaPods internal GCC_PREPROCESSOR_DEFINITIONS found here https://github.com/CocoaPods/CocoaPods/blob/master/lib/cocoapods/project.rb#L275-L294

but there is no overall logic that copies over these build settings from the user to that target.

[jshier]

Right. I guess this is a combination bug report (unexpected behavior, especially in regards to the Pods project having configurations that don't exist in my project at all) and feature request (more settings from my project should be copied to the Pods project). The lack of these settings being transferred has led to user bugs in the past, especially when the optimization settings of the app don't match those of the pods. Plus, if I create new configurations that aren't supposed to use any optimization, building the pods with optimization adds unnecessary build time, meaning special configurations for testing don't have the performance a user would expect.

[RamblinWreck77]

This bug was driving me absolutely batty today.

I'm on 1.6.0 rc2 and @dnkoutso your comment helped me fix it.

project 'BuildSettingsShouldMatch', 'NewDebug' => :debug

must be at the top of your podfile

I previously had it inside my target do's like so:

target 'BuildSettingsShouldMatch1' do
        >>> Here
end

Did not consistently set my custom configuration to DEBUG, in fact oddly enough it would do something like:

-Debug << New config that isn't in my xcode proj
-Debug_vendor1 << Correctly set to debug
-Debug_vendor2 << would be in release mode

[jshier]

So I'm looking into this again, since I'm trying to use more custom build configurations as a replacement for multiple targets. There seems to be a few different CP behaviors at play here.

1. CocoaPods always creates Debug and Release build configurations, even if you're not using them at all.
2. CocoaPods will create configs that match the names of the integrating target's build configs, but the settings aren't inherited at all, so they're all set to Release-like settings by default.
3. Using the workaround @dnkoutso mentioned above, you can get some of the settings to look like Debug and others to look like Release, but they still don't inherit settings from the integrating target, which is the most important part, otherwise you can't properly control certain settings on a per-config basis.

If I do want to control these settings, is my only option at this point to use a post_install hook to set them manually?

Ultimately it seems like this issue comes down to CocoaPods using Xcodeproj's settings instead of the integrating target's, right? It seems like it should inherit instead, as not only are the various defaults from Xcodeproj wildly out of date but could break the build in various ways if they don't match the target's. Which of these behaviors are intentional and which aren't? Which should be improved?

[RamblinWreck77]

Ultimately it seems like this issue comes down to CocoaPods using Xcodeproj's settings instead of the integrating target's, right? It seems like it should inherit instead, as not only are the various defaults from Xcodeproj wildly out of date but could break the build in various ways if they don't match the target's.

@jshier I completely agree. My song and dance with cocoapods is currently:

-pod outdated -> pod update, because of a new release
-delete the Debug and Release configs cocoapods decided to add out of nowhere
-Wait for xcode to maybe tell me the project settings need to be updated. This involves clean build, let the index happen, then quit/launch xcode 3-4 times. Eventually you get the "update project to recommended settings" prompt in warnings and you can apply it, typically setting "build for active architectures" or something in tons of places.

I had to remove pod install from our fastlane deploy scripts because cocaopods doing anything borks the project until you do the above

[dcow]

+1 I would love support for this.

[StefanNituFitmo]

Any updates on this issue? :)

[amorde]

If there were updates they would be posted here :) contributions welcome!

If CocoaPods were to start copying over build settings from the user project, we would need to support _not_ doing this as this may not be desired behavior. Some other potential improvements:

• Emit a warning if there's a mis-match between the configurations that exist in the user's project and the default Debug/Release created by CocoaPods
• If a project only has 1 configuration, only create 1 configuration in the Pods project

[iSame7]

Still having same issue, any update?