Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

xcconfig inheritance issues #115

Closed
lukeredpath opened this Issue · 5 comments

5 participants

@lukeredpath

There may be another issue similar to this, but this is an issue I've had in recent days with CocoaPods and multiple targets.

This is a very basic example. I have a project with a static library target, and a unit test bundle for that target. I have some testing libraries that I only want to link to my unit test bundle so I create a separate, exclusive target in my Podfile, e.g.:

platform :ios

# some dependencies for my static lib

target :specs, :exclusive => true do
  # some dependencies for my test bundle
end

Now, in my project, libPods is linked to my static library target (CocoaPods does this for me automatically I think) and I've linked libPods-specs to my unit test bundle target.

Finally, I link my static library target to my unit test bundle so I can exercise the code within that static library in my tests (this is my preference, it seems much cleaner than adding each file you want to test in your library to your test bundle individually).

Now here's the problem. From what I can tell, Xcode will only let you specify one xcconfig file for each target. Naturally, you'd assume I'd base my library target on Pods.xcconfig, and my test bundle on Pods-specs.xcconfig.

Now, because my specs Pod target is exclusive, Pods-specs.xcconfig will contain none of the configuration for my library target, including things like dependent frameworks and libraries that needed to be linked to the project, header search paths etc. This means that my test bundle won't compile unless I manually add these dependencies to the target, which kind of defeats the whole point of using pods.

I could make the specs target non-exclusive, however that would mean that libPods-specs would share objects that are in libPods, and because my libPods is linked to my library target, which is in turn linked to my specs target, which means I'll get duplicate object errors. This won't work.

So, what's the solution? It seems like there is a need to have aggregate or inherited configs, without inheriting dependencies.

As an example, perhaps something like this would work:

platform :ios

# some dependencies for my static lib

# :root is a special value, referring the top-level target, it could be another named target

target :specs, :exclusive => true, :inherits_config_from => :root do
  # some dependencies for my test bundle
end

This would result in a libPods-specs that only contained my test bundle dependencies, but Pods-specs.xcconfig would contain the aggregate config from Pods.xcconfig plus the config for it's own target's dependencies.

Any thoughts?

@alloy
Owner

My idea was to create a ‘Pods.xcconfig’ and a ‘definitions.xcconfig’ for each Pods target. The latter would define things like specs_LD_FLAGS = -lz, while the former would then include that and define LD_FLAGS = specs_LD_FLAGS.

This means it will be possible to include definitions from other targets and combine them. E.g. LD_FLAGS = root_LD_FLAGS specs_LD_FLAGS. And this could then indeed be automated with your :inherits_config_from idea.

@rulien

Is there any solution or a better workaround than manually changing project settings file ?

@qnoid

Have come across this issue as well. It looks like #144 was created to address this but can't see any progress.
However, it's not consistent.

On a fresh checkout of the project, under the same XCode version, using Cocoapods 0.15.2 get different xcconfig files.

One includes the headers of the dependencies while the other one doesn't.
Which makes me wonder if could be some difference in the gems used by Cocoapods.

Let me know if I can provide you with anything tangible.

@qnoid

Let me add that have noticed this in the past with version 0.7.0 as well.
Have updated to 0.16.1 on one of the installations exhibiting the behaviour and it is working as expected.

However, since it appears to be an interim every now an then, will raise it again under 0.16.1 if it occurs.

@fabiopelosin

Moving to #833

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.