c++11 pod compile error on cocoapods 0.22.1

[belkevich]

Hi!
I have project that uses CedarAsync for BDD-testing. And everything were fine until I've update cocoapods from 0.20.2 to 0.22.1. And after that I couldn't build CedarAsync pod anymore!
The problem is in C++11 extensions that used by CedarAsync. And I've found in XCode "build settings" some parameter that set version of C++ for pods to c++0x. I've changed it to c++11, but still got compile error.
Do you have any ideas how to fix it?

[alloy]

Unfortunately not. Please figure out the exact build setting issue and then provide a reduced sample project, so we can fix this.

[belkevich]

You can try to build my project with cocoapods 0.22.1 (Version 0.20.x works fine). It's pretty simple. Just run pod command in "Spec" folder. And open RequestManagerSpec.xcworkspace
I've found two "user defined" settings in "project settings":
PODS_CEDAR_CLANG_CXX_LANGUAGE_STANDARD = c++0x
PODS_CEDAR_CLANG_CXX_LIBRARY = libc++
Unfortunately I have no idea how to remove this settings.
Also, there are no such settings with cocoapods 0.20.x

[alloy]

Thanks, that makes it much clearer :)

So the build failure happens in Pods-CedarAsync, the reason for this is that it’s missing those settings that you’ve mentioned, which are only applied to Pods-Cedar.

In short, the Pods-CedarAsync spec is technically broken, because it actually requires those build settings. It previously worked because before CP 0.22.x, the build settings of all pods in a target were shared, which was basically polluting the build env of individual pods.

The fix is basically this change to the CedarAsync spec, but unfortunately this leads to another failure, namely the stdlib being specified twice in the Pods target. I.e. in Pods.xcconfig, this:

CLANG_CXX_LANGUAGE_STANDARD =  ${PODS_CEDAR_CLANG_CXX_LANGUAGE_STANDARD} ${PODS_CEDARASYNC_CLANG_CXX_LANGUAGE_STANDARD}
CLANG_CXX_LIBRARY =  ${PODS_CEDAR_CLANG_CXX_LIBRARY} ${PODS_CEDARASYNC_CLANG_CXX_LIBRARY}

Expands to:

CLANG_CXX_LANGUAGE_STANDARD = c++0x c++0x
CLANG_CXX_LIBRARY = libc++ libc++

So I can’t push this spec change yet, until we have a fix for such duplicated values, but you should be able to apply the fix locally and change the contents of Pods.xcconfig to hardcode the fixed values:

#include "Pods-ABMultiton.xcconfig"
#include "Pods-Cedar.xcconfig"
#include "Pods-CedarAsync.xcconfig"
#include "Pods-OCFuntime.xcconfig"
#include "Pods-OHHTTPStubs.xcconfig"
#include "Pods-SCNetworkReachability.xcconfig"
CLANG_CXX_LANGUAGE_STANDARD = c++0x
CLANG_CXX_LIBRARY = libc++
GCC_PREPROCESSOR_DEFINITIONS = $(inherited) COCOAPODS=1
HEADER_SEARCH_PATHS = "${PODS_ROOT}/Headers" "${PODS_ROOT}/Headers/ABMultiton" "${PODS_ROOT}/Headers/Cedar" "${PODS_ROOT}/Headers/Cedar/Cedar-iOS" "${PODS_ROOT}/Headers/CedarAsync" "${PODS_ROOT}/Headers/OCFuntime" "${PODS_ROOT}/Headers/OHHTTPStubs" "${PODS_ROOT}/Headers/SCNetworkReachability"
OTHER_LDFLAGS = -ObjC ${PODS_OHHTTPSTUBS_OTHER_LDFLAGS} ${PODS_SCNETWORKREACHABILITY_OTHER_LDFLAGS}
PODS_ROOT = ${SRCROOT}/Pods

[alloy]

@irrationalfab Before releasing 0.22.2 I’m going to look into this bug.

[alloy]

@irrationalfab @jasl8r So instead of referencing the namespaced variables, I collect the actual values and combined with this change in Xcodeproj the values will never be duplicated. I feel like I might be overlooking something, let me know if you see a reason this shouldn’t be done this way.

[alloy]

Released 0.22.2.

[alloy]

I have now also pushed the spec change: CocoaPods/Specs@e2c3ec4

[belkevich]

Thanks guys! Everything works fine now!

[alloy]

Good to hear! 🍻

[fabiopelosin]

@alloy 👍 I'm wondering if a similar issue might arise in the xcconfigs of the aggregate targets.

[alloy]

@irrationalfab This was at the aggregate level, so I have only changed the AggregateXCConfig class.

[fabiopelosin]

Sorry, I read the implementation too quickly. Indeed it makes sense. However doesn't this means that we will not be able to use the variables to allow to configure the xcconfigs more easily as originally planned?

[alloy]

However doesn't this means that we will not be able to use the variables to allow to configure the xcconfigs more easily as originally planned?

Right now, yes. So we need to discuss how we want it to be configurable, the simplest approach would probably be to do the aggregate target in the same way as the other targets.