Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Dedicated targets #1011

Merged
merged 57 commits into from

4 participants

@jasl8r

Supersedes pull request #983.

jasl8r and others added some commits
@jasl8r jasl8r 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.
1d51f82
@jasl8r jasl8r Identify copy build phase by spec name fbfea26
@jasl8r jasl8r Only add a single Manifest.lock phase when dealing with multiple specs 5cb58ad
@jasl8r jasl8r Add specs to libraries for non-integrated targets 5bd2bf7
@jasl8r jasl8r Merge branch 'master' into dedicated-targets 9a71521
@jasl8r jasl8r Support xcconfig files per Podfile target
Xcconfig files are generated for every library target and target 
defined in the Podfile.  However, only the Podfile target xcconfig 
files are added to the user project.  This required tracking all the 
libraries as well as the Podfile targets through the installation and 
integration procedures.
717dc51
@fabiopelosin fabiopelosin Merge branch 'dedicated-targets' of https://github.com/jasl8r/CocoaPods
… into jasl8r-dedicated-targets

* 'dedicated-targets' of https://github.com/jasl8r/CocoaPods:
  Support xcconfig files per Podfile target
  Add specs to libraries for non-integrated targets
  Only add a single Manifest.lock phase when dealing with multiple specs
  Identify copy build phase by spec name
  Add per-spec static library targets
397eaa9
@jasl8r jasl8r referenced this pull request
Closed

Add dedicated targets #983

@coveralls

Coverage Status

Changes Unknown when pulling 397eaa9 on dedicated-targets into ** on master**.

@jasl8r

Continuing the conversation:

There should be only one library and one xcconfig for the client target, I've just tested creating a stating lib which simply lists the other ones as dependencies and it appear that there are no issues going with this route.

This makes sense. At one point I thought there was a potential issue here with object name collisions, but it appears that libtool just presents a warning and everything works, so this seems okay. This probably simplifies some of the things in my most recent commit, by making all generated content a real libraries again.

I'm not sure about the xcconfig as I haven't yet completely read your patch, but from my quick experimentation you are not creating one which includes all the others (and thus the resulting project is working only because the old xcconfig was not deleted).

There is a top level xcconfig created per target definition. There is no longer a top level Pods library (see above), but an xcconfig file is generated for every spec/library and one for every target definition that is applied to every appropriate target.

The values are just a mash up of the spec dependency values, but maybe you would want a hierarchy where xcconfigs include other xcconfigs?

Only one copy resource script should be created per target.

Makes sense, it was getting messy in the target.

Finally in the common xccofing all the headers of all the targets should be made visible (temporarily) until an adequate DSL is implemented to fix #904.

There was always an xcconfig per target definition, right? Why not just put dependent headers in each xcconfig. Doesn't this solve #904 without any introduced DSL?

@fabiopelosin fabiopelosin Merge branch 'master' into dedicated-targets
* master:
  Release 0.19.1
  [Integration] Update version in fixtures
  CHANGELOG [skip ci]
  [TargetInstaller] Create unique hash instances for the build settings
  [Generator::Xcconfig] Add inherited to GCC_PREPROCESSOR_DEFINITIONS
  Changelog [ci skip]

Conflicts:
	lib/cocoapods/generator/xcconfig.rb
c9235c6
@fabiopelosin

There is a top level xcconfig created per target definition.

Sorry, I missed it. Great!

The values are just a mash up of the spec dependency values, but maybe you would want a hierarchy where xcconfigs include other xcconfigs?

Exactly each pod should generate a namespaced variable for each key of the xcconfig like (AFNetworking):

// Pods-AFNetworking.xcconfig
AFNETWORKING_OTHER_LDFLAGS = -ObjC -framework CoreServices -framework Security -framework SystemConfiguration

Then the xcconfig of each library should just reference the variables:

// Pods.xcconfig
#include "Pods-AFNetworking.xcconfig"
OTHER_LDFLAGS = $(AFNETWORKING_OTHER_LDFLAGS) $(OBJECTIVE_SUGAR_OTHER_LDFLAGS) $(inherited) 

/c @alloy @CocoaPods/core

@fabiopelosin

There was always an xcconfig per target definition, right? Why not just put dependent headers in each xcconfig. Doesn't this solve #904 without any introduced DSL?

I'm referring to this comment. Currently there is no way to specify that an integrated target should only inherit the headers of the parent. This is common in test targets which depend on a another target integrated with CocoaPods. Without a dedicated DSL it would either be not possible to reference the headers of the tested target or there would be errors related to the duplication of the symbols of all the pods inherited by the parent target definition.

@fabiopelosin

In other words #904 is easy to fix, but we need a way to specify that a target should include the headers of the parent before doing that.

@jasl8r

Okay, I get it now.

@jasl8r jasl8r Add Pods integration library
Adds the libPods.a and target derivatives back as targets in the Pods 
project.  The integration libraries are simple containers linked with 
all of the per spec libraries to create a single library for the user 
project to link with.  The xcconfig file for the integration library 
merges namespaced config settings for all dependent specs for use by 
the user project.
3868eba
@coveralls

Coverage Status

Coverage remained the same when pulling 3868eba on dedicated-targets into 11dca2a on master.

jasl8r added some commits
@jasl8r jasl8r Remove nil specs and pods from installer rep maps 28ca8f5
@jasl8r jasl8r Don't install library without target definition 195ec17
@jasl8r jasl8r Keep shell script phase simple and static
The copy resources shell script phase was previously updated every 
time the pods were changed.  This moves the updates to the integration 
library copy resources script and restores the original static single 
line from before the per pod library code.
352e8d1
@jasl8r jasl8r Only integrate with targets that require it
This restores and merges the original code for determining if a 
user target requires integration.
0551e51
@jasl8r jasl8r Bug fixes and cleanup 2638169
@jasl8r jasl8r Update test specs
Many changes are simple API changes, generally centered around the 
renaming of Library to Target.

There are also a lot of additional stubbed or test classes added to 
accommodate for the fact that real Pods installations always have one 
or more integration libraries each with one or more per spec 
libraries.
1f5198d
@jasl8r

So with the latest set of changes, the tests are all completing. Although I had one failure with docuementation both on master and my branch, so everything that I broke is now passing.

The only functional change was to restore the copy resources phase to a more classic approach of running a single generic Pods-resources.sh script, and the Pods-resources.sh script is dynamically generated to call all the per spec resource scripts. This should keep the install process stable as pod dependencies change in the Podfile.

@coveralls

Coverage Status

Coverage remained the same when pulling 1f5198d on dedicated-targets into 11dca2a on master.

@jasl8r

Well I guess there is a whole slew of other integration tests that are failing...

@fabiopelosin
Owner

I have updated the integration fixtures. To do it in the future you can run $ rake spec:rebuild_integration_fixtures. These checks are set in place in order to test the exact products of a CP install (and so they might need to be updated often).

@coveralls

Coverage Status

Coverage remained the same when pulling 838092d on dedicated-targets into 11dca2a on master.

fabiopelosin added some commits
@fabiopelosin fabiopelosin Merge branch 'master' into dedicated-targets
* master:
  [Rakefile] Perform setup on for integration only if needed 2
  [Rakefile] Don't set the git user as not needed anymore
  [Rakefile] Perform setup on for integration only if needed.
  [Doc] Make clear that an error occurred in a pre/post hook.
4178969
@fabiopelosin fabiopelosin [Integration] Update fixtures 2 8fb3317
@coveralls

Coverage Status

Coverage remained the same when pulling 8fb3317 on dedicated-targets into d931a75 on master.

jasl8r added some commits
@jasl8r jasl8r Move integration library linking outside of target integrator
The target integrator is only run when libraries are being integrated 
with user projects.  The Pods integration library needs to be 
updated, linked with the spec libraries, regardless of user 
project integration.
22ad845
@jasl8r jasl8r Quote copy resources scripts d379f48
@jasl8r jasl8r Manually build dependencies with xcodebuild
The xcodebuild -target <target> invocation does not support implicit 
dependencies.  Therefor building the Pods integration library fails 
because none of the spec libraries are built.  Building a scheme 
results in proper implicit dependency resolution, but there are no 
schemes created in the integration tests.  Just walk the list of 
spec libraries and manually build all dependencies before building 
the Pod integration library.
df7a027
@jasl8r jasl8r Configure integration targets without specs daa6752
@coveralls

Coverage Status

Coverage remained the same when pulling daa6752 on dedicated-targets into d931a75 on master.

@jasl8r

So how exactly should the output of rebuilding the integration fixtures be vetted? There are a few files, execution_output that include paths to git for instance, which on my system is /usr/local/git/bin/git.

@fabiopelosin
Owner

So how exactly should the output of rebuilding the integration fixtures be vetted?

Manually, they are a final sanity check on the products of a CocoaPods installation. In this case the change is extensive and after checking a couple of folders, the others can be scanned quickly. Another goal of this design is to allow quickly identify which commit produced an unexpected change.

There are a few files, execution_output that include paths to git for instance, which on my system is /usr/local/git/bin/git.

Currently there is some logic to make this file execution agnostic unfortunately it is not yet robust, feel free to amend it to your needs.

@fabiopelosin
Owner

I have tested this patch with a complex Podfile and the results are good! :+1:

At the moment I was only able to review the Xcconfig file. After toying around a bit with it I noticed that the current implementation might be fragile: the xcconfigs of the Pods need to include non namespaced settings as they are used to build the library as well. As they are included in the target xcconfig they might set a configuration which is valid unless overridden and which is hard to trace back. At this point I'm wondering wether we should create two xcconfigs: one namespaced for inclusion and one used to build the Pod target.

lib/cocoapods/generator/xcconfig.rb
@@ -50,21 +60,43 @@ def generate
ld_flags << ' -fobjc-arc'
end
- @xcconfig = Xcodeproj::Config.new({
- 'ALWAYS_SEARCH_USER_PATHS' => 'YES',
- 'OTHER_LDFLAGS' => ld_flags,
- 'HEADER_SEARCH_PATHS' => '${PODS_HEADERS_SEARCH_PATHS}',
- 'PODS_ROOT' => relative_pods_root,
- 'PODS_HEADERS_SEARCH_PATHS' => '${PODS_PUBLIC_HEADERS_SEARCH_PATHS}',
- 'PODS_BUILD_HEADERS_SEARCH_PATHS' => quote(sandbox.build_headers.search_paths),
- 'PODS_PUBLIC_HEADERS_SEARCH_PATHS' => quote(sandbox.public_headers.search_paths),
- 'GCC_PREPROCESSOR_DEFINITIONS' => '$(inherited) COCOAPODS=1'
- })
-
- spec_consumers.each do |consumer|
- add_spec_build_settings_to_xcconfig(consumer, @xcconfig)
+ if library.spec
@fabiopelosin Owner

I propose to split this class in two: one xcconfig generator for the Pods and one for the target definitions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
lib/cocoapods/generator/xcconfig.rb
((9 lines not shown))
- 'PODS_HEADERS_SEARCH_PATHS' => '${PODS_PUBLIC_HEADERS_SEARCH_PATHS}',
- 'PODS_BUILD_HEADERS_SEARCH_PATHS' => quote(sandbox.build_headers.search_paths),
- 'PODS_PUBLIC_HEADERS_SEARCH_PATHS' => quote(sandbox.public_headers.search_paths),
- 'GCC_PREPROCESSOR_DEFINITIONS' => '$(inherited) COCOAPODS=1'
- })
-
- spec_consumers.each do |consumer|
- add_spec_build_settings_to_xcconfig(consumer, @xcconfig)
+ if library.spec
+ config = {
+ 'ALWAYS_SEARCH_USER_PATHS' => 'YES',
+ 'OTHER_LDFLAGS' => ld_flags,
+ 'PODS_ROOT' => '${SRCROOT}',
+ 'HEADER_SEARCH_PATHS' => quote(library.build_headers.search_paths) + ' ' + quote(sandbox.public_headers.search_paths),
+ 'GCC_PREPROCESSOR_DEFINITIONS' => 'COCOAPODS=1',
+ # 'USE_HEADERMAP' => 'NO'
@fabiopelosin Owner

For the moment I'm disabling this feature, which I propose to handle after this patch, as the isolation of the headers is another issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
lib/cocoapods/generator/xcconfig.rb
((12 lines not shown))
- 'GCC_PREPROCESSOR_DEFINITIONS' => '$(inherited) COCOAPODS=1'
- })
-
- spec_consumers.each do |consumer|
- add_spec_build_settings_to_xcconfig(consumer, @xcconfig)
+ if library.spec
+ config = {
+ 'ALWAYS_SEARCH_USER_PATHS' => 'YES',
+ 'OTHER_LDFLAGS' => ld_flags,
+ 'PODS_ROOT' => '${SRCROOT}',
+ 'HEADER_SEARCH_PATHS' => quote(library.build_headers.search_paths) + ' ' + quote(sandbox.public_headers.search_paths),
+ 'GCC_PREPROCESSOR_DEFINITIONS' => 'COCOAPODS=1',
+ # 'USE_HEADERMAP' => 'NO'
+ }
+
+ consumer_xcconfig(library.consumer).to_hash.each do |k, v|
@fabiopelosin Owner

This feature in my opinion should be implemented in Xcodeproj directly. If we generate two xcconfigs (one for import and one for building) we could implement:

def save_as(pathname, prefix = nil)
  pathname.open('w') { |file| file << to_s(prefix) }
end

Then #to_s should forward the optional prefix (a string) to #to_hash which is needed maps the generated hash to a new one where the keys are prefixed.

Related: CocoaPods/Xcodeproj#68

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
lib/cocoapods/generator/xcconfig.rb
((6 lines not shown))
#
- def add_spec_build_settings_to_xcconfig(consumer, xcconfig)
+ def consumer_xcconfig(consumer)
@fabiopelosin Owner

There is something which doesn't sounds right here. The Pods library have a single consumer. However a Pod might include multiple specs (subspecs) so it can have multiple consumers. I haven't read the whole implementation so I'm not sure if this is taken into account somewhere else.

@jasl8r
jasl8r added a note

So does a top level spec with multiple subspecs need any information from the subspecs in its xcconfig? As it is now, a top level spec will act just like any other spec or subspec, no xcconfig settings will be inherited from a subspec into a parent spec.

@fabiopelosin Owner

Subspecs can define xcconfig settings as well. And in this case the only thing that we can do is to apply those settings to the target of the Pod. Not perfect but it should be good enough as atm all the settings of all the specs are applied to whole target definition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
lib/cocoapods/hooks/installer_representation.rb
@@ -60,7 +60,8 @@ def libraries
def specs_by_lib
result = {}
installer.libraries.each do |lib|
- result[installer.library_rep(lib)] = lib.specs
+ next if lib.spec == nil
@fabiopelosin Owner

I'm not sure if the Library (now Target) class should be used for the Pods targets as well. I need to check, but I think that the most of the functionality it provides is geared to common not needed by the Pods targets. For example currently multiple environments, acknowledgments, and copy resource script files are generated. Those files are needed only for the target definition target (this is getting complicated we need a better syntax to differentiate with the Pods targets while discussing :smile: ). It the needs of the two targets are different it might be appropriate also to split the target installer providing helper classes for the common functionality if needed.

@jasl8r
jasl8r added a note

As discussed earlier, this makes sense and would certainly simply, or at least better organize, the code in a number of other places. The Pods Targets / Integration Libraries also don't need build_headers, file_accessors, and probably others.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
lib/cocoapods/installer.rb
@@ -322,6 +323,22 @@ def install_targets
end
end
+ # Links the integration library targets with all the dependent libraries
+ #
+ # @note This is run in the integration step to ensure that targets
+ # have been created for all per spec libraries.
+ #
+ def link_integration_libraries
+ targets.each do |target|
+ native_target = pods_project.targets.select { |t| t.name == target.name }.first
+ products = pods_project.products_group
+ target.libraries.each do |library|
+ product = products.files.select { |f| f.path == library.product_name }.first
+ native_target.frameworks_build_phase.add_file_reference(product)
@fabiopelosin Owner

As a note, sooner or later I'm planning to move this to the xcconfig to pave the way to #731.

@jasl8r
jasl8r added a note

So do you mean moving the linking step away from the target frameworks build phase and into an OTHER_LDFLAGS setting in the xcconfig? If so, you'll lose implicit linking/building, right? You'll have to add the linker flags to the xcconfig and probably add explicit target dependencies to the target. If this is what you mean, I suppose a benefit, is that the xcodebuild step that I changed in df7a027 can revert.

@fabiopelosin Owner

@alloy Can you share your take?

@alloy Owner
alloy added a note

@irrationalfab I agree with your point regarding moving it into the xcconfig for #731.

@jasl8r Regarding df7a027, did you see my messages in Campfire from just before you joined?

In any case, where possible, we should be able to generate something that will build all the dependencies in isolation. I.e. without having to integrate it into a user project. We use this often to test a Podfile that a user pastes into a issue ticket or for a project like RubyMotion which only wants the resulting static library. I guess that means that CocoaPods should always generate a workspace, regardless of the use of --no-integrate.

Another potential issue is that currently people can integrate Pods.xcodeproj manually as a subproject, but I guess that's not going to be possible anymore?

Finally, just out of curiousity and because I haven’t checked that out yet, will the Pods.xcodeproj have aggregate targets that generate one static library by lipo-ing all the dependency libs together?

@jasl8r
jasl8r added a note

Actually, creating a workspace doesn't solve the issue. The problem is that the implicit dependency resolution only works when building a scheme (from what I can tell). A scheme isn't created until the project / workspace is opened.

I think what I suggested works well though. Add target references for all of a Pods dependencies to the Target Dependencies phase. This alone resolves the command line building. To address #731, just remove the library references from the Frameworks Build Phase and add the linker flags to a private xcconfig file for the integration library (libPods.a).

This does generate an aggregate static library, but through linking, not through lipo. So the result is a single libPods.a (and libPods-target-definition.a for other target definitions).

If an end user needs the whole project to build from the command line without generating a scheme, then there is still a problem, but this doesn't work today either, and it can't be solved with a target dependency because you can't add target dependencies across projects in a workspace. Although, you can add a target dependency from another project that is in a parent projects embedded workspace... but I think I've gotten off topic here.

@fabiopelosin Owner

I think what I suggested works well though. Add target references for all of a Pods dependencies to the Target Dependencies phase. This alone resolves the command line building. To address #731, just remove the library references from the Frameworks Build Phase and add the linker flags to a private xcconfig file for the integration library (libPods.a).

:+1:

This does generate an aggregate static library, but through linking, not through lipo. So the result is a single libPods.a (and libPods-target-definition.a for other target definitions).

@alloy Did you mean to generate an additional single lib for the whole Pods project?

Another potential issue is that currently people can integrate Pods.xcodeproj manually as a subproject, but I guess that's not going to be possible anymore?

Why is not going to be possible? Actually I think that this patch is a pre-requisite for this option of integration. Because with this patch is much easier to edit the Pod project in place (just recreate the targets of the changed pods).

and it can't be solved with a target dependency because you can't add target dependencies across projects in a workspace.

Haven't tested it in the UI. But there is something interesting here.

@alloy Owner
alloy added a note

@irrationalfab Never mind those remarks… :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@fabiopelosin fabiopelosin commented on the diff
...nstaller/user_project_integrator/target_integrator.rb
@@ -127,9 +143,11 @@ def add_pods_library
# @return [void]
#
def add_copy_resources_script_phase
- targets.each do |target|
- phase = target.new_shell_script_build_phase('Copy Pods Resources')
- path = library.copy_resources_script_relative_path
+ phase_name = "Copy Pods Resources"
+ native_targets.each do |native_target|
+ phase = native_target.shell_script_build_phases.select { |bp| bp.name == phase_name }.first ||
@fabiopelosin Owner

This is a good example to why it might be a good idea to split this class in something like PodsTargetInstaller and LibTargetInstaller

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@fabiopelosin fabiopelosin commented on the diff
lib/cocoapods/sandbox.rb
@@ -67,7 +63,6 @@ class Sandbox
#
def initialize(root)
@root = Pathname.new(root)
- @build_headers = HeadersStore.new(self, "BuildHeaders")
@public_headers = HeadersStore.new(self, "Headers")
@fabiopelosin Owner

Now that we use to aggregate variables, the Pods Targets (ex Library) should keep track of the headers search paths.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
...all_add_pod/after/Pods/Pods-Acknowledgements.markdown
@@ -1,17 +1,3 @@
# Acknowledgements
This application makes use of the following third party libraries:
-
@fabiopelosin Owner

This file should not be modified in the final patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
lib/cocoapods/target.rb
((37 lines not shown))
@target_definition = target_definition
+ @sandbox = sandbox
+ @build_headers = Sandbox::HeadersStore.new(sandbox, "BuildHeaders")
@fabiopelosin Owner

I take back my above comment about the headers :smile:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
lib/cocoapods/target.rb
((6 lines not shown))
#
- attr_accessor :specs
+ attr_accessor :spec
@fabiopelosin Owner

Again the point that Pods can have multiple specs (I should have commented here)

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

After discussing with @alloy the implementation of the xcconfigs inheritance should be similar to what described in this gist (in opposition to the current implementation described in this one).

@fabiopelosin fabiopelosin Merge branch 'master' into dedicated-targets
* master: (34 commits)
  [SpecHelper] Use coveralls head which fixes issues with colored
  [Integration] Update fixtures for Generator::CopyResourcesScript
  [Generator::CopyResourcesScript] Clean-up
  Update CHANGELOG.md
  Update CHANGELOG
  [Gemspec] Include sandbox-pod
  [SanboxBin] Include /usr/libexec
  [Sandbox] Reading from paths that contain executables should be safe.
  [Sandbox] Remove doc generation related rules and allow for more prefixes. (E.g. MacPorts.)
  [Search] Show all command options.
  [Travis] No need to install Mercurial anymore 2
  [Travis] No need to install Mercurial anymore
  [Complete] Fix copy resources script for iOS < 6 and OS X < 10.8
  added issue link to the fix
  updated changelog for inhibit_warnings fix
  [Changelog]
  [Specs] Refine output
  [Specs] Facelift inspired to xctool
  [Changelog]
  [Integration] Use aggressive cache
  ...

Conflicts:
	lib/cocoapods/installer/target_installer.rb
	spec/integration/install_external_source/after/Pods/Pods-resources.sh
	spec/integration/install_local_source/after/Pods/Pods-resources.sh
b9dfaa9
@coveralls

Coverage Status

Coverage remained the same when pulling b9dfaa9 on dedicated-targets into cfabfaa on master.

@jasl8r

After discussing with @alloy the implementation of the xcconfigs inheritance should be similar to what described in this gist (in opposition to the current implementation described in this one).

So this makes sense, and I will go ahead and add the prefixing/namespacing support to Xcodeproj.

Again the point that Pods can have multiple specs (I should have commented here)

So there are really two types of targets generated. Spec targets which represent a podspec or even a subspec and Pod targets which are just the intermediate targets for integrating with user projects. Do you have an example where I still need to track multiple specs in a Spec target?

@jasl8r jasl8r Split targets and supporting classes into single purpose classes
Target class converted to PodTarget and SpecTarget representing Pod 
integration targets and podspec targets.
TargetInstaller converted to PodTargetInstaller and 
SpecTargetInstaller to handle variations in installing Pod targets 
and spec targets.
XCConfig generator converted to PodXCConfig, PublicSpecXCCconfig and 
PrivateSpecXCConfig classes to handle generating the different 
xcconfig files.
Requires Xcodeproj file changes to support namespaced xcconfig files.
01fc944
@coveralls

Coverage Status

Coverage remained the same when pulling 01fc944 on dedicated-targets into cfabfaa on master.

@jasl8r

Latest changes depend on CocoaPods/Xcodeproj#70. There is still a lot of prefix generation in the XCConfig classes in CocoaPods, only simple prefix support is added in CocoaPods/Xcodeproj#70. I don't see an easy way to move this out of CocoaPods, but maybe this is what you are looking for.

@coveralls

Coverage Status

Coverage remained the same when pulling 806463e on dedicated-targets into cfabfaa on master.

fabiopelosin added some commits
@fabiopelosin fabiopelosin Merge branch 'master' into dedicated-targets
* master:
  [ErrorReport] Fix issues search url
  Pods-resources.sh: Generate newlines between install_resource calls
  [Sandbox] Try to make an educated guess as to where the MacPorts prefix is.
  [Sandbox] Small cleanup.
  [Changelog] Add note about the path option and the sandbox [ci skip]
  [Command::Help] Show root help with 'pod help'
  [Specs] Use pretty bacon
  [Command] default to install
  [CHANGELOG] Add note about other package managers than Homebrew.
  [CHANGELOG] Cleanup last addition regarding sandbox.
  [CHANGELOG] Introduce the experimental sandbox feature.
  [Gemfile] Adopt local git repos feature of Bunlder
  [CopyResourcesScript] Fix permissions
  Update CHANGELOG.md
  [CopyResourcesScript] Restore compatiblity with Ruby 1.8.7
  [SpecHelper] Use Coveralls only in Ruby > 1.8
  [Gemspec] Bump json dep
  [SpecHelper] Don't require simplecov in Ruby 1.8.x
24b0a27
@fabiopelosin fabiopelosin [Gemfile] Require xcconfig-prefix branch for Xcodeproj 9b3de5a
@coveralls

Coverage Status

Coverage remained the same when pulling 9b3de5a on dedicated-targets into be7e588 on master.

@coveralls

Coverage Status

Coverage remained the same when pulling 3d3ab97 on dedicated-targets into be7e588 on master.

@fabiopelosin

@jasl8r Please note that I have swapped the PodTarget name as seen in the above commits.

@coveralls

Coverage Status

Coverage remained the same when pulling b87c2e8 on dedicated-targets into be7e588 on master.

@coveralls

Coverage Status

Coverage remained the same when pulling 5adc5c7 on dedicated-targets into be7e588 on master.

@coveralls

Coverage Status

Coverage remained the same when pulling 2b6f390 on dedicated-targets into be7e588 on master.

@jasl8r

Are you indicating here, and the label def seems to confirm this, that there should only be a single target generated for a top level spec? The way I designed it was that every spec and subspec generates a target. I think this is simpler, especially considering that subspecs can apply different xcconfig overrides, includes, etc. Subspecs are effectively full podspecs just contained, namespaced, in a parent spec, correct, so why not make a target for every subspec?

Are you indicating here, and the label def seems to confirm this, that there should only be a single target generated for a top level spec?

Yes, one target for all the specs (root and activated subspecs) of a Pod.

Subspecs are effectively full podspecs just contained, namespaced, in a parent spec, correct, so why not make a target for every subspec?

For CocoaPods this true, but they are used to group parts which are not guaranteed to be compilable independently. Moreover many subspecs depend on a shared common one (usually called Core) and the linking should be properly setup for this setup (I think that this issue has not been addressed even for dependencies across Pods, is that correct?).

As there haven't been many issues with pollution of the build environment with the current setup I would not worry about this issue for the moment. This is not a definitive answer as I would need to investigate more if your proposed setup could create issues.

/c @alloy

@fabiopelosin

@jasl8r can you push your work?

@jasl8r

Hey, sorry I've been MIA, I was going to finish my tests and push, but the problem is that the changes you pushed to regroup specs with subspecs as a single target broke a few other things, minimally the target generation in the analyzer but possibly more. Anyway, I got swamped at work and home, but I'll have time this weekend to get back to it.

@fabiopelosin

Yeah, I noticed that I created some havoc with my refactoring :expressionless:. Sorry about that. This is the reason why I've asked for your push, so I could be able to contribute on top of it.

@alloy
Owner

TODO for after this is done: #1075.

jasl8r added some commits
@jasl8r jasl8r Fix old target methods naming 363af1f
@jasl8r jasl8r Create a single PodTarget for all subspecs
Group all related specs in the Analyzer.
Make sure to add all FileAccessors for each subspec in the Installer.
e8d61f3
@jasl8r jasl8r XCConfig is generated for Pod targets as well a760745
@jasl8r

Still working on the tests, but fixed this stuff up for now...

fabiopelosin added some commits
@fabiopelosin fabiopelosin Merge branch 'master' into dedicated-targets
* master: (46 commits)
  Use Kicker from master
  [Changelog] Fixed crash due to Podfile.lock containing multiple version requirements.
  [Integration] Update fixtures
  * Truncating the resources-to-copy.txt file if it already exists.
  [Travis] Attempt to fix 1.9.3 Issues
  Remove Rake dependency
  [Specs] Remove old uneeded integration spec
  [Core] Update for recent changes
  [Bundler] Add Gemfile.lock to source control and update Bundler on release
  Remove Octokit dep 2
  [WIP] Remove Octokit dep
  Fix missing space in output.
  english fix for 'Podfile does not contain any dependency'
  Release 0.20.2
  [Sandbox] Allow sandbox-pod to execute any tool inside a rbenv prefix.
  Bump to 0.20.2
  [CHANGELOG] Cleanup.
  [Spec] Update integrations specs for 0.20.2
  [CHANGELOG] Update for 0.20.2
  [Sandbox] Allow any tool inside the Xcode.app bundle to be executed.
  ...

Conflicts:
	spec/integration/install_add_pod/after/Pods/Pods-resources.sh
	spec/integration/install_custom_workspace/after/Podfile.lock
	spec/integration/install_custom_workspace/after/Pods/Manifest.lock
	spec/integration/install_external_source/after/Pods/Pods-resources.sh
	spec/integration/install_local_source/after/Pods/Pods-resources.sh
	spec/integration/install_multiple_targets/after/Pods/Pods-SampleApp_2-resources.sh
	spec/integration/install_multiple_targets/after/Pods/Pods-resources.sh
	spec/integration/install_multiple_targets/after/Pods/Pods-test-resources.sh
	spec/integration/install_new/after/Pods/Pods-resources.sh
	spec/integration/install_podfile_callbacks/after/Pods/Pods-resources.sh
	spec/integration/install_podspec/after/Pods/Pods-resources.sh
	spec/integration/install_remove_pod/after/Pods/Pods-resources.sh
	spec/integration/install_spec_callbacks/after/Pods/Pods-resources.sh
	spec/integration/install_subspecs/after/Podfile.lock
	spec/integration/install_subspecs/after/Pods/Manifest.lock
	spec/integration/update/after/Pods/Pods-resources.sh
	spec/integration_spec.rb
	spec/unit/installer_spec.rb
0304d9d
@fabiopelosin fabiopelosin [Specs] Fix require paths 6413187
@coveralls

Coverage Status

Coverage remained the same when pulling 6413187 on dedicated-targets into c4fedc5 on master.

@jasl8r

Looks like a minor failure in the integration specs 2, not sure why. I can't actually complete a spec run locally due to odd git issues...

@fabiopelosin

The failure was related to those files being modified after the checkout by git. Moreover git add was not working. After a quick troubleshoot I tried to add and remove them and this appeared to fix the issue. The issue might be related to case sensitivity. Are you on a case sensitive file system?

@fabiopelosin fabiopelosin Merge branch 'master' into dedicated-targets
* master:
  [Spec] Rebuild integration test fixtures.
  Use a different resources-to-copy.txt file for each target
  Grammar fix in CONTRIBUTING file
  Made SO link to our search query
  [CONTRIBUTING] Add back links to ML and SO. Thanks @secboffin.
  [CONTRIBUTING] Make it even clearer/simpler. Thanks to @Manfred.
  [CONTRIBUTING] Try to be as clear as possible about do's and don'ts.

Conflicts:
	spec/integration/install_add_pod/after/Pods/Pods.xcodeproj.yaml
	spec/integration/install_add_pod/after/execution_output.txt
	spec/integration/install_custom_workspace/after/Pods/Pods.xcodeproj.yaml
	spec/integration/install_custom_workspace/after/execution_output.txt
	spec/integration/install_external_source/after/Pods/Pods.xcodeproj.yaml
	spec/integration/install_external_source/after/SampleApp.xcodeproj.yaml
	spec/integration/install_external_source/after/execution_output.txt
	spec/integration/install_local_source/after/Pods/Pods.xcodeproj.yaml
	spec/integration/install_local_source/after/SampleApp.xcodeproj.yaml
	spec/integration/install_multiple_targets/after/Pods/Pods.xcodeproj.yaml
	spec/integration/install_multiple_targets/after/SampleApp.xcodeproj.yaml
	spec/integration/install_multiple_targets/after/execution_output.txt
	spec/integration/install_new/after/Pods/Pods.xcodeproj.yaml
	spec/integration/install_new/after/execution_output.txt
	spec/integration/install_podfile_callbacks/after/Pods/Pods.xcodeproj.yaml
	spec/integration/install_podfile_callbacks/after/execution_output.txt
	spec/integration/install_podspec/after/Pods/Pods.xcodeproj.yaml
	spec/integration/install_podspec/after/execution_output.txt
	spec/integration/install_remove_pod/after/Pods/Pods.xcodeproj.yaml
	spec/integration/install_spec_callbacks/after/Pods/Pods.xcodeproj.yaml
	spec/integration/install_spec_callbacks/after/execution_output.txt
	spec/integration/install_subspecs/after/Pods/Pods.xcodeproj.yaml
	spec/integration/install_subspecs/after/SampleApp.xcodeproj.yaml
	spec/integration/install_subspecs/after/execution_output.txt
	spec/integration/update/after/Pods/Pods.xcodeproj.yaml
	spec/integration/update/after/execution_output.txt
d7f9903
@coveralls

Coverage Status

Coverage remained the same when pulling d7f9903 on dedicated-targets into b1ac8b2 on master.

@fabiopelosin

I have tested this patch either integrating from scratch and integrating an existing installation and it is working properly. I've also reviewed it and everything looks good to me. Please feel free to edit/clarify the note about this patch in the changelog and let me know if you would prefer to acknowledged by full name as we use to do (is not a secret but I noticed that you didn't include it in your profile). Moreover, we usually acknowledge great contributions with a tweet therefore please let me know you user name (unless you are not interested).

I think that a couple of days after the dust of the WWDC keynote has settled we can release an RC.

I can't overstate how impressed I am with your contribution! :+1:

@coveralls

Coverage Status

Coverage remained the same when pulling 519c2fc on dedicated-targets into b1ac8b2 on master.

@jasl8r

Awesome, thanks! You can use my full name, that's fine. On twitter I am also jasl8r.

@fabiopelosin fabiopelosin merged commit 519c2fc into master
@fabiopelosin fabiopelosin deleted the dedicated-targets branch
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Apr 18, 2013
  1. @jasl8r

    Add per-spec static library targets

    jasl8r authored
    Static library targets are created for each combination of user-target
    and spec dependency.  This addresses issue #841, although likely not 
    entirely.
  2. @jasl8r
  3. @jasl8r
Commits on Apr 19, 2013
  1. @jasl8r
  2. @jasl8r
Commits on Apr 26, 2013
  1. @jasl8r

    Support xcconfig files per Podfile target

    jasl8r authored
    Xcconfig files are generated for every library target and target 
    defined in the Podfile.  However, only the Podfile target xcconfig 
    files are added to the user project.  This required tracking all the 
    libraries as well as the Podfile targets through the installation and 
    integration procedures.
Commits on Apr 29, 2013
  1. @fabiopelosin

    Merge branch 'dedicated-targets' of https://github.com/jasl8r/CocoaPods

    fabiopelosin authored
    … into jasl8r-dedicated-targets
    
    * 'dedicated-targets' of https://github.com/jasl8r/CocoaPods:
      Support xcconfig files per Podfile target
      Add specs to libraries for non-integrated targets
      Only add a single Manifest.lock phase when dealing with multiple specs
      Identify copy build phase by spec name
      Add per-spec static library targets
Commits on Apr 30, 2013
  1. @fabiopelosin

    Merge branch 'master' into dedicated-targets

    fabiopelosin authored
    * master:
      Release 0.19.1
      [Integration] Update version in fixtures
      CHANGELOG [skip ci]
      [TargetInstaller] Create unique hash instances for the build settings
      [Generator::Xcconfig] Add inherited to GCC_PREPROCESSOR_DEFINITIONS
      Changelog [ci skip]
    
    Conflicts:
    	lib/cocoapods/generator/xcconfig.rb
Commits on May 2, 2013
  1. @jasl8r

    Add Pods integration library

    jasl8r authored
    Adds the libPods.a and target derivatives back as targets in the Pods 
    project.  The integration libraries are simple containers linked with 
    all of the per spec libraries to create a single library for the user 
    project to link with.  The xcconfig file for the integration library 
    merges namespaced config settings for all dependent specs for use by 
    the user project.
Commits on May 6, 2013
  1. @jasl8r
  2. @jasl8r
  3. @jasl8r

    Keep shell script phase simple and static

    jasl8r authored
    The copy resources shell script phase was previously updated every 
    time the pods were changed.  This moves the updates to the integration 
    library copy resources script and restores the original static single 
    line from before the per pod library code.
  4. @jasl8r

    Only integrate with targets that require it

    jasl8r authored
    This restores and merges the original code for determining if a 
    user target requires integration.
  5. @jasl8r

    Bug fixes and cleanup

    jasl8r authored
  6. @jasl8r

    Update test specs

    jasl8r authored
    Many changes are simple API changes, generally centered around the 
    renaming of Library to Target.
    
    There are also a lot of additional stubbed or test classes added to 
    accommodate for the fact that real Pods installations always have one 
    or more integration libraries each with one or more per spec 
    libraries.
  7. @fabiopelosin
  8. @fabiopelosin

    Merge branch 'master' into dedicated-targets

    fabiopelosin authored
    * master:
      [Rakefile] Perform setup on for integration only if needed 2
      [Rakefile] Don't set the git user as not needed anymore
      [Rakefile] Perform setup on for integration only if needed.
      [Doc] Make clear that an error occurred in a pre/post hook.
  9. @fabiopelosin
Commits on May 7, 2013
  1. @jasl8r

    Move integration library linking outside of target integrator

    jasl8r authored
    The target integrator is only run when libraries are being integrated 
    with user projects.  The Pods integration library needs to be 
    updated, linked with the spec libraries, regardless of user 
    project integration.
  2. @jasl8r

    Quote copy resources scripts

    jasl8r authored
  3. @jasl8r

    Manually build dependencies with xcodebuild

    jasl8r authored
    The xcodebuild -target <target> invocation does not support implicit 
    dependencies.  Therefor building the Pods integration library fails 
    because none of the spec libraries are built.  Building a scheme 
    results in proper implicit dependency resolution, but there are no 
    schemes created in the integration tests.  Just walk the list of 
    spec libraries and manually build all dependencies before building 
    the Pod integration library.
  4. @jasl8r
Commits on May 9, 2013
  1. @fabiopelosin
Commits on May 17, 2013
  1. @fabiopelosin

    Merge branch 'master' into dedicated-targets

    fabiopelosin authored
    * master: (34 commits)
      [SpecHelper] Use coveralls head which fixes issues with colored
      [Integration] Update fixtures for Generator::CopyResourcesScript
      [Generator::CopyResourcesScript] Clean-up
      Update CHANGELOG.md
      Update CHANGELOG
      [Gemspec] Include sandbox-pod
      [SanboxBin] Include /usr/libexec
      [Sandbox] Reading from paths that contain executables should be safe.
      [Sandbox] Remove doc generation related rules and allow for more prefixes. (E.g. MacPorts.)
      [Search] Show all command options.
      [Travis] No need to install Mercurial anymore 2
      [Travis] No need to install Mercurial anymore
      [Complete] Fix copy resources script for iOS < 6 and OS X < 10.8
      added issue link to the fix
      updated changelog for inhibit_warnings fix
      [Changelog]
      [Specs] Refine output
      [Specs] Facelift inspired to xctool
      [Changelog]
      [Integration] Use aggressive cache
      ...
    
    Conflicts:
    	lib/cocoapods/installer/target_installer.rb
    	spec/integration/install_external_source/after/Pods/Pods-resources.sh
    	spec/integration/install_local_source/after/Pods/Pods-resources.sh
Commits on May 19, 2013
  1. @jasl8r

    Split targets and supporting classes into single purpose classes

    jasl8r authored
    Target class converted to PodTarget and SpecTarget representing Pod 
    integration targets and podspec targets.
    TargetInstaller converted to PodTargetInstaller and 
    SpecTargetInstaller to handle variations in installing Pod targets 
    and spec targets.
    XCConfig generator converted to PodXCConfig, PublicSpecXCCconfig and 
    PrivateSpecXCConfig classes to handle generating the different 
    xcconfig files.
    Requires Xcodeproj file changes to support namespaced xcconfig files.
  2. @jasl8r
Commits on May 21, 2013
  1. @fabiopelosin

    Merge branch 'master' into dedicated-targets

    fabiopelosin authored
    * master:
      [ErrorReport] Fix issues search url
      Pods-resources.sh: Generate newlines between install_resource calls
      [Sandbox] Try to make an educated guess as to where the MacPorts prefix is.
      [Sandbox] Small cleanup.
      [Changelog] Add note about the path option and the sandbox [ci skip]
      [Command::Help] Show root help with 'pod help'
      [Specs] Use pretty bacon
      [Command] default to install
      [CHANGELOG] Add note about other package managers than Homebrew.
      [CHANGELOG] Cleanup last addition regarding sandbox.
      [CHANGELOG] Introduce the experimental sandbox feature.
      [Gemfile] Adopt local git repos feature of Bunlder
      [CopyResourcesScript] Fix permissions
      Update CHANGELOG.md
      [CopyResourcesScript] Restore compatiblity with Ruby 1.8.7
      [SpecHelper] Use Coveralls only in Ruby > 1.8
      [Gemspec] Bump json dep
      [SpecHelper] Don't require simplecov in Ruby 1.8.x
  2. @fabiopelosin
  3. @fabiopelosin
  4. @fabiopelosin
  5. @fabiopelosin
  6. @fabiopelosin

    [Target] Cleanup

    fabiopelosin authored
    * rename libraries to #pod_targets
    * introduce support for multiple specs in the PodTarget
  7. @fabiopelosin
  8. @fabiopelosin
  9. @fabiopelosin
  10. @fabiopelosin
Commits on Jun 3, 2013
  1. @jasl8r

    Fix old target methods naming

    jasl8r authored
  2. @jasl8r

    Create a single PodTarget for all subspecs

    jasl8r authored
    Group all related specs in the Analyzer.
    Make sure to add all FileAccessors for each subspec in the Installer.
  3. @jasl8r
Commits on Jun 5, 2013
  1. @fabiopelosin

    Merge branch 'master' into dedicated-targets

    fabiopelosin authored
    * master: (46 commits)
      Use Kicker from master
      [Changelog] Fixed crash due to Podfile.lock containing multiple version requirements.
      [Integration] Update fixtures
      * Truncating the resources-to-copy.txt file if it already exists.
      [Travis] Attempt to fix 1.9.3 Issues
      Remove Rake dependency
      [Specs] Remove old uneeded integration spec
      [Core] Update for recent changes
      [Bundler] Add Gemfile.lock to source control and update Bundler on release
      Remove Octokit dep 2
      [WIP] Remove Octokit dep
      Fix missing space in output.
      english fix for 'Podfile does not contain any dependency'
      Release 0.20.2
      [Sandbox] Allow sandbox-pod to execute any tool inside a rbenv prefix.
      Bump to 0.20.2
      [CHANGELOG] Cleanup.
      [Spec] Update integrations specs for 0.20.2
      [CHANGELOG] Update for 0.20.2
      [Sandbox] Allow any tool inside the Xcode.app bundle to be executed.
      ...
    
    Conflicts:
    	spec/integration/install_add_pod/after/Pods/Pods-resources.sh
    	spec/integration/install_custom_workspace/after/Podfile.lock
    	spec/integration/install_custom_workspace/after/Pods/Manifest.lock
    	spec/integration/install_external_source/after/Pods/Pods-resources.sh
    	spec/integration/install_local_source/after/Pods/Pods-resources.sh
    	spec/integration/install_multiple_targets/after/Pods/Pods-SampleApp_2-resources.sh
    	spec/integration/install_multiple_targets/after/Pods/Pods-resources.sh
    	spec/integration/install_multiple_targets/after/Pods/Pods-test-resources.sh
    	spec/integration/install_new/after/Pods/Pods-resources.sh
    	spec/integration/install_podfile_callbacks/after/Pods/Pods-resources.sh
    	spec/integration/install_podspec/after/Pods/Pods-resources.sh
    	spec/integration/install_remove_pod/after/Pods/Pods-resources.sh
    	spec/integration/install_spec_callbacks/after/Pods/Pods-resources.sh
    	spec/integration/install_subspecs/after/Podfile.lock
    	spec/integration/install_subspecs/after/Pods/Manifest.lock
    	spec/integration/update/after/Pods/Pods-resources.sh
    	spec/integration_spec.rb
    	spec/unit/installer_spec.rb
  2. @fabiopelosin
Commits on Jun 10, 2013
  1. @jasl8r
  2. @jasl8r
  3. @jasl8r

    Fix developer framework path

    jasl8r authored
  4. @jasl8r

    Add default_ld_flags method

    jasl8r authored
    The -fobjc-arc flag should only be added when explicitly requested in 
    the Podfile and the spec requires arc.
  5. @jasl8r
  6. @jasl8r

    Move method below attributes

    jasl8r authored
  7. @jasl8r

    Update tests

    jasl8r authored
  8. @jasl8r
  9. @jasl8r
  10. @fabiopelosin
  11. @fabiopelosin
  12. @fabiopelosin

    Merge branch 'master' into dedicated-targets

    fabiopelosin authored
    * master:
      [Spec] Rebuild integration test fixtures.
      Use a different resources-to-copy.txt file for each target
      Grammar fix in CONTRIBUTING file
      Made SO link to our search query
      [CONTRIBUTING] Add back links to ML and SO. Thanks @secboffin.
      [CONTRIBUTING] Make it even clearer/simpler. Thanks to @Manfred.
      [CONTRIBUTING] Try to be as clear as possible about do's and don'ts.
    
    Conflicts:
    	spec/integration/install_add_pod/after/Pods/Pods.xcodeproj.yaml
    	spec/integration/install_add_pod/after/execution_output.txt
    	spec/integration/install_custom_workspace/after/Pods/Pods.xcodeproj.yaml
    	spec/integration/install_custom_workspace/after/execution_output.txt
    	spec/integration/install_external_source/after/Pods/Pods.xcodeproj.yaml
    	spec/integration/install_external_source/after/SampleApp.xcodeproj.yaml
    	spec/integration/install_external_source/after/execution_output.txt
    	spec/integration/install_local_source/after/Pods/Pods.xcodeproj.yaml
    	spec/integration/install_local_source/after/SampleApp.xcodeproj.yaml
    	spec/integration/install_multiple_targets/after/Pods/Pods.xcodeproj.yaml
    	spec/integration/install_multiple_targets/after/SampleApp.xcodeproj.yaml
    	spec/integration/install_multiple_targets/after/execution_output.txt
    	spec/integration/install_new/after/Pods/Pods.xcodeproj.yaml
    	spec/integration/install_new/after/execution_output.txt
    	spec/integration/install_podfile_callbacks/after/Pods/Pods.xcodeproj.yaml
    	spec/integration/install_podfile_callbacks/after/execution_output.txt
    	spec/integration/install_podspec/after/Pods/Pods.xcodeproj.yaml
    	spec/integration/install_podspec/after/execution_output.txt
    	spec/integration/install_remove_pod/after/Pods/Pods.xcodeproj.yaml
    	spec/integration/install_spec_callbacks/after/Pods/Pods.xcodeproj.yaml
    	spec/integration/install_spec_callbacks/after/execution_output.txt
    	spec/integration/install_subspecs/after/Pods/Pods.xcodeproj.yaml
    	spec/integration/install_subspecs/after/SampleApp.xcodeproj.yaml
    	spec/integration/install_subspecs/after/execution_output.txt
    	spec/integration/update/after/Pods/Pods.xcodeproj.yaml
    	spec/integration/update/after/execution_output.txt
  13. @fabiopelosin
  14. @fabiopelosin
  15. @fabiopelosin
  16. @fabiopelosin

    [CHANGELOG]

    fabiopelosin authored
Something went wrong with that request. Please try again.