CocoaPods/CocoaPods — Issue #115: xcconfig inheritance issues
Author: lukeredpath
Created: 2012-02-10 00:29:04+00:00
State: open

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.:

```ruby
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:

```ruby
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?