Isolate Pods in dedicated targets #841

Closed
fabiopelosin opened this Issue Mar 9, 2013 · 3 comments

Comments

Projects
None yet
3 participants
@fabiopelosin
Member

fabiopelosin commented Mar 9, 2013

From @AliSoftware comment in #125 .

This would allow to:

  • Prevent prefix header contamination.
  • Easily modifying (as opposed to recreating from scratch) the Pods project as it would be possible to just clear the folders and the targets of the modified and deleted pods.
    • Speed up builds as the pods project is only modified.
    • Reduce versioning issues #143
    • Allow to add the pods project to the user project (if the user wants) #94
  • Link with different libraries/frameworks based on the build configuration. #731

This should be done for each Pod - target combination as there might be differences (a common example is iOS and OS X builds).

@JaviSoto

This comment has been minimized.

Show comment
Hide comment
@JaviSoto

JaviSoto Mar 26, 2013

+1

+1

@jasl8r

This comment has been minimized.

Show comment
Hide comment
@jasl8r

jasl8r Apr 18, 2013

Contributor

Is anyone currently working on this issue? I am asking because I have put together a solution that works for my use cases, but I am very new to the project and I wanted to confer.

This solution works with multiple project targets and subspecs. I haven't looked into build configurations yet.

My need for this solution is similar to the prefix header contamination, but due to header or source conflicts when two different projects have the same header name. For example, two 3rd party libraries might both have a config.h.

My solution creates a static library target for every combination of library dependency / user target pair and ensures that each library is built in a 'sandbox' by not allowing project level includes (USE_HEADERMAP = NO). I will put up my work to date shortly, but I haven't fixed up any of the tests. I'm not sure if what I have put together even fits with the developers plans.

Contributor

jasl8r commented Apr 18, 2013

Is anyone currently working on this issue? I am asking because I have put together a solution that works for my use cases, but I am very new to the project and I wanted to confer.

This solution works with multiple project targets and subspecs. I haven't looked into build configurations yet.

My need for this solution is similar to the prefix header contamination, but due to header or source conflicts when two different projects have the same header name. For example, two 3rd party libraries might both have a config.h.

My solution creates a static library target for every combination of library dependency / user target pair and ensures that each library is built in a 'sandbox' by not allowing project level includes (USE_HEADERMAP = NO). I will put up my work to date shortly, but I haven't fixed up any of the tests. I'm not sure if what I have put together even fits with the developers plans.

@fabiopelosin

This comment has been minimized.

Show comment
Hide comment
@fabiopelosin

fabiopelosin Apr 18, 2013

Member

Awesome. To my knowledge there hasn't been anybody working on this. So please make a pull request (even without the tests) so we can inspect your patch. If you are interested in polishing it to get it merged I can help!

Member

fabiopelosin commented Apr 18, 2013

Awesome. To my knowledge there hasn't been anybody working on this. So please make a pull request (even without the tests) so we can inspect your patch. If you are interested in polishing it to get it merged I can help!

jasl8r added a commit to jasl8r/CocoaPods that referenced this issue Apr 18, 2013

Add per-spec static library targets
Static library targets are created for each combination of user-target
and spec dependency.  This addresses issue #841, although likely not 
entirely.

jzapater pushed a commit to jzapater/CocoaPods that referenced this issue Sep 17, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment