Skip to content

Loading…

Expose only the appropriate header to each target #904

Closed
amolloy opened this Issue · 11 comments

8 participants

@amolloy

In a Podfile with multiple targets, all targets have their HEADER_SEARCH_PATHS set to the full set of header folders for every pod mentioned in the podfile, regardless of whether the target uses that pod or not.

A sample Podfile demonstrating this issue:

target :TestiOS do
   platform :ios, '6'
   pod 'HockeySDK'
end
target :TestMac do
   platform :osx, '10.8'
   pod 'NSLogger' 
end

The resulting Pods-TestMac.xcconfig is:

ALWAYS_SEARCH_USER_PATHS = YES
HEADER_SEARCH_PATHS = ${PODS_HEADERS_SEARCH_PATHS}
OTHER_LDFLAGS = -ObjC -framework CFNetwork -framework CoreServices -framework SystemConfiguration
PODS_BUILD_HEADERS_SEARCH_PATHS = "${PODS_ROOT}/BuildHeaders" "${PODS_ROOT}/BuildHeaders/HockeySDK" "${PODS_ROOT}/BuildHeaders/NSLogger"
PODS_HEADERS_SEARCH_PATHS = ${PODS_PUBLIC_HEADERS_SEARCH_PATHS}
PODS_PUBLIC_HEADERS_SEARCH_PATHS = "${PODS_ROOT}/Headers" "${PODS_ROOT}/Headers/HockeySDK" "${PODS_ROOT}/Headers/NSLogger"
PODS_ROOT = ${SRCROOT}/Pods

Note the presence of both NSLogger and HockeySDK in the header search paths. The generated xcconfig for TestiOS is similar.

I would expect targets to only have search paths for the pods used by that target. For example, Pods-TextMac.xcconfig should look like:

ALWAYS_SEARCH_USER_PATHS = YES
HEADER_SEARCH_PATHS = ${PODS_HEADERS_SEARCH_PATHS}
OTHER_LDFLAGS = -ObjC -framework CFNetwork -framework CoreServices -framework SystemConfiguration
PODS_BUILD_HEADERS_SEARCH_PATHS = "${PODS_ROOT}/BuildHeaders" "${PODS_ROOT}/BuildHeaders/NSLogger"
PODS_HEADERS_SEARCH_PATHS = ${PODS_PUBLIC_HEADERS_SEARCH_PATHS}
PODS_PUBLIC_HEADERS_SEARCH_PATHS = "${PODS_ROOT}/Headers" "${PODS_ROOT}/Headers/NSLogger"
PODS_ROOT = ${SRCROOT}/Pods

This becomes an issue if pods included by different targets have different header files with the same name. For example, this came up for me while trying to create a Podspec for the HockeySDK-Mac framework and using it in a project alongside the already existing HockeySDK podspec. Both versions of Hockey's SDK involve headers with matching names but very different content. Since all targets get all pods headers in their header search paths, this situation breaks.

This happens with both cocoapods 0.16.4 and 0.17.0.rc7.

@alloy
CocoaPods member

Agreed. We won’t have much time to work on things the rest of this week (because of a conference), if you could whip-up a patch that would be great.

@fabiopelosin
CocoaPods member

This issue requires #840 as there is the practice of relying on this behavior for test targets which include the tested target

pod 'App-pod'
target 'test', :exclusive => true do
  # This target is exclusive but needs the headers of the parent.
  pod 'test-pod'
end
@pellet

I manually removed the other target's header path's from the first target's .xcconfig but the wrong header would still be included within the pod project file.
I managed to get around the problem by adding the User-defined setting - USE_HEADERMAP=NO underneath the POD User-defined settings.
I definitely agree that CocoaPods should have at the very least have an option for mutually exclusive search paths for separate targets.

This was referenced
@michaelmelanson

I am still experiencing this issue. I have a Podfile that looks like this:

target :MyApplicationIOS do
    platform :ios, :deployment_target => "6.0"

    pod "DependencyA"
    pod "DependencyB"
end

target :MyApplicationOSX do
    platform :osx, :deployment_target => "10.7"

    pod "DependencyA"
    pod "DependencyB"
    pod "Chameleon" # real dependency
end

However, the .xcconfig files for the iOS target has HEADER_SEARCH_PATHS that include the headers for the Chameleon dependency. The expected behaviour would be for both of the targets to include the headers for the common dependencies, but only the OSX target would include headers for the Chameleon target.

What's the status of this issue? Are there any workarounds for this?

@michaelmelanson michaelmelanson added a commit to toushay/CocoaPods that referenced this issue
@michaelmelanson michaelmelanson [CocoaPods/CocoaPods#904] Separate header paths for different targets…
… in .xcconfig files.
771b31c
@michaelmelanson michaelmelanson added a commit to toushay/CocoaPods that referenced this issue
@michaelmelanson michaelmelanson [CocoaPods/CocoaPods#904] Separate header paths for different targets…
… in .xcconfig files.
b22f340
@michaelmelanson michaelmelanson added a commit to toushay/CocoaPods that referenced this issue
@michaelmelanson michaelmelanson Added note in the CHANGELOG about fix for #904. d645e26
@shvekiasaf

I'm still experiencing the issue. Is there any solution? or even workaround for this?

@michaelmelanson

@shvekiasaf Yes, I fixed the issue and created a pull request to have it merged in. Check out either the pull request or the Toushay/CocoaPods fork.

@shvekiasaf
@michaelmelanson

Glad to help.

@marksands marksands referenced this issue
Closed

Clean up Podfile syntax #840

0 of 7 tasks complete
@kylef
CocoaPods member

Duplicate of #1249.

@kylef kylef closed this
@bcattle

This issue's closed as a duplicate of one with no comments that was opened after it??

@michaelmelanson

I feel your pain, and I'm really annoyed by how the project maintainers have handled this issue. I submitted a pull request almost a year ago that was initially treated positively but eventually ignored because there was work on the go for #840 and #1249 that would fix this problem.

Now, almost a year later, this bug is still open and we cannot use the official fork of CocoaPods because of it. I'm left in the position that our fork at toushay/CocoaPods has fallen so far behind that I must bring ourselves up to date to keep using CocoaPods. But that means spending time forward porting our changes to take into account a year's worth of changes to CocoaPods.

I want an answer here about the status of this issue. If I update pull request #1590, will it be merged in? Or am I just wasting my time here?

cc @kylef @fabiopelosin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.