Add :include_headers_for option #144

Closed
petejkim opened this Issue Mar 1, 2012 · 19 comments

Comments

Projects
None yet
4 participants

petejkim commented Mar 1, 2012

Some targets may only require headers and not actual compiled symbols, for example ocunit target, in order to avoid the dreaded duplicate symbol errors.

For example, this Podfile:

platform :ios

dependency 'ASIHTTPRequest', '~> 1.8.1'
dependency 'ConciseKit',     '~> 0.1.1'
dependency 'SBJson',         '~> 3.0.4'

target :test, :exclusive => true, :include_headers_for => :default do
  dependency 'Specta',       '~> 0.1.4'
  dependency 'Expecta',      '~> 0.1.3'
  dependency 'OCMock',       '~> 1.77.1'
  dependency 'OCHamcrest',   '~> 1.6'
end

should generate the following Pods-test.xcconfig :

PODS_ROOT = $(SRCROOT)/Pods
HEADER_SEARCH_PATHS = "$(PODS_ROOT)/Headers" "$(PODS_ROOT)/Headers/ASIHTTPRequest" "$(PODS_ROOT)/Headers/ConciseKit" "$(PODS_ROOT)/Headers/Expecta" "$(PODS_ROOT)/Headers/OCHamcrest" "$(PODS_ROOT)/Headers/OCMock" $(PODS_ROOT)/Headers/Reachability" "$(PODS_ROOT)/Headers/SBJson" "$(PODS_ROOT)/Headers/Specta"
ALWAYS_SEARCH_USER_PATHS = YES
OTHER_LDFLAGS = -ObjC -all_load -framework Foundation -ObjC -framework Foundation -framework SenTestingKit
FRAMEWORK_SEARCH_PATHS = "$(DEVELOPER_FRAMEWORKS_DIR)"
LD_RUNPATH_SEARCH_PATHS = "$(DEVELOPER_FRAMEWORKS_DIR)"

i.e. including headers for dependencies defined in the :default target, but without having those dependencies compiled in libPods-Test.a

I tried hacking some code to add this functionality on my own, but I am having trouble running the specs...

Could someone help implement this, or at least help me do it?

Owner

alloy commented Mar 1, 2012

It could be that the way we’ll do this will change once we create xcconfig files that can be mixed and matched, but, assuming this will be a small feature code-wise, until then this seems like a good idea.

What do you need assistance with specifically?

Contributor

lukeredpath commented Mar 1, 2012

Referencing #115 as this seems like an alternative/complementary solution to some of the issues I discussed there.

petejkim commented Mar 2, 2012

I am unable to run some spces. How do I set up the environment so that the specs will run correctly?

Owner

alloy commented Mar 2, 2012

Setting up:

$ gem install bundler
$ bundle install

Running all specs:

$ bundle exec rake spec

Running specific specs:

$ bundle exec bacon spec/unit/installer_spec.rb

It will probably work without prefixing the commands with bundle exec, but prefixing will make sure it works.

petejkim commented Mar 2, 2012

yep of course i did those, i am a rubyist. the specs just don't work. There's an infinite loop of

cd ./external/Xcodeproj && rake ext:clean
(in /Users/jihoon/workspace/CocoaPods)
cd ./external/Xcodeproj && rake ext:clean
(in /Users/jihoon/workspace/CocoaPods)
cd ./external/Xcodeproj && rake ext:clean
(in /Users/jihoon/workspace/CocoaPods)
cd ./external/Xcodeproj && rake ext:clean
(in /Users/jihoon/workspace/CocoaPods)
cd ./external/Xcodeproj && rake ext:clean
(in /Users/jihoon/workspace/CocoaPods)
cd ./external/Xcodeproj && rake ext:clean
(in /Users/jihoon/workspace/CocoaPods)

so I tried running specs individually, and this works:

bacon spec/unit/podfile_spec.rb

- loads from a file
- assigns the platform attribute
- adds dependencies
- adds a dependency on a Pod repo outside of a spec repo (the repo is expected to contain a podspec)
- adds a dependency on a library outside of a spec repo (the repo does not need to contain a podspec)
- adds a dependency on a library by specifying the podspec inline
- specifies that BridgeSupport metadata should be generated
- stores a block that will be called with the Installer instance once installation is finished (but the project is not written to disk yet)
concerning targets (dependency groups)
- returns wether or not a target has any dependencies
- returns all dependencies of all targets combined, which is used during resolving to enusre compatible dependencies
- adds dependencies outside of any explicit target block to the default target
- adds dependencies of the outer target to non-exclusive targets
- does not add dependencies of the outer target to exclusive targets
- does not add dependency, but adds headers to targets that specify :include_headers_for option
- adds dependencies of the outer target to nested targets

concerning validations
- raises if no platform is specified
- raises if an invalid platform is specified
- raises if no dependencies were specified


18 specifications (31 requirements), 0 failures, 0 errors

but not

bacon spec/unit/installer_spec.rb

Pod::Installer
, by default,
- sets the header search paths where installed Pod headers can be found [ERROR: Pod::Informative]
- configures the project to load categories from the static library [ERROR: Pod::Informative]

- generates a BridgeSupport metadata file from all the pod headers [ERROR: Pod::Informative]
- omits empty target definitions [ERROR: Pod::Informative]

Pod::Informative: No spec repos found in `/Users/jihoon/workspace/CocoaPods/tmp/cocoapods'. To fetch the `master' repo run: $ pod setup
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/source.rb:7:in `all': , by default, - sets the header search paths where installed Pod headers can be found
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/source.rb:15:in `search'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:41:in `find_dependency_set'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:15:in `block in find_dependency_sets'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:14:in `each'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:14:in `find_dependency_sets'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:9:in `resolve'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:7:in `dependent_specifications'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:11:in `build_specifications'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:38:in `project'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:52:in `block in target_installers'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:51:in `map'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:51:in `target_installers'
    spec/unit/installer_spec.rb:6:in `block (3 levels) in <top (required)>'
    spec/unit/installer_spec.rb:12:in `block (2 levels) in <top (required)>'
    spec/unit/installer_spec.rb:4:in `block in <top (required)>'
    spec/unit/installer_spec.rb:3:in `<top (required)>'

Pod::Informative: No spec repos found in `/Users/jihoon/workspace/CocoaPods/tmp/cocoapods'. To fetch the `master' repo run: $ pod setup
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/source.rb:7:in `all': , by default, - configures the project to load categories from the static library
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/source.rb:15:in `search'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:41:in `find_dependency_set'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:15:in `block in find_dependency_sets'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:14:in `each'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:14:in `find_dependency_sets'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:9:in `resolve'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:7:in `dependent_specifications'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:11:in `build_specifications'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:38:in `project'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:52:in `block in target_installers'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:51:in `map'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:51:in `target_installers'
    spec/unit/installer_spec.rb:6:in `block (3 levels) in <top (required)>'
    spec/unit/installer_spec.rb:18:in `block (2 levels) in <top (required)>'
    spec/unit/installer_spec.rb:4:in `block in <top (required)>'
    spec/unit/installer_spec.rb:3:in `<top (required)>'

Pod::Informative: Unable to find a pod named `ASIHTTPRequest'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/source.rb:16:in `search': Pod::Installer - generates a BridgeSupport metadata file from all the pod headers
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:41:in `find_dependency_set'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:15:in `block in find_dependency_sets'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:14:in `each'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:14:in `find_dependency_sets'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:9:in `resolve'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:7:in `dependent_specifications'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:11:in `build_specifications'
    spec/unit/installer_spec.rb:43:in `block (2 levels) in <top (required)>'
    spec/unit/installer_spec.rb:35:in `block in <top (required)>'
    spec/unit/installer_spec.rb:3:in `<top (required)>'

Pod::Informative: Unable to find a pod named `JSONKit'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/source.rb:16:in `search': Pod::Installer - omits empty target definitions
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:41:in `find_dependency_set'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:15:in `block in find_dependency_sets'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:14:in `each'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:14:in `find_dependency_sets'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/resolver.rb:9:in `resolve'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:7:in `dependent_specifications'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:11:in `build_specifications'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:38:in `project'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:52:in `block in target_installers'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:51:in `map'
    /Users/jihoon/workspace/CocoaPods/lib/cocoapods/installer.rb:51:in `target_installers'
    spec/unit/installer_spec.rb:60:in `block (2 levels) in <top (required)>'
    spec/unit/installer_spec.rb:51:in `block in <top (required)>'
    spec/unit/installer_spec.rb:3:in `<top (required)>'

4 specifications (0 requirements), 0 failures, 4 errors
Owner

alloy commented Mar 2, 2012

Ah I see. I think you are missing the git submodules, which amongst others, fetches the specs into ./spec/fixtures/spec-repos.

$ git submodule update --init

petejkim commented Mar 2, 2012

Ah I see. It seems to work now, thanks!

Owner

alloy commented Mar 2, 2012

There’s a wiki page about setting up for development, but it needs some love.

Contributor

lukeredpath commented Mar 2, 2012

FWIW, I find that I do need to use bundle exec although I have it aliased to be in my shell.

Small confession: I'm not a big lover of bacon, I find it's error output to be less than helpful unfortunately.

Owner

alloy commented Mar 2, 2012

What I like about Bacon is that it’s so small that it’s easy to customize for each project. Can you give me examples of what you find unhelpful?

Contributor

lukeredpath commented Mar 2, 2012

As long as the specs run fast enough, I like to run them directly from within TextMate. What I find is that the output (bacon default I think) when a test fails is...well there isn't any. It just says its failed. If you know of a way I can fix that please tell me!

Owner

alloy commented Mar 2, 2012

The default ‘spec’ style formatter only displays next to the description wether or not it failed, but then it prints the failures with backtrace at the end of the run. I’ll run them from TextMate tonight to see what it shows.

@petejkim petejkim added a commit to petejkim/CocoaPods that referenced this issue Mar 6, 2012

@petejkim petejkim rudimentary support for :include_headers_for option. #144 c39b7ea

petejkim commented Mar 6, 2012

it appears that there's been some major refactoring happening in master... the above commit causes conflicts... :(

Owner

alloy commented Mar 6, 2012

Yeah, sorry about that :)

Btw, why did you decide to do another resolve pass? Can’t we just ask the ‘from’ target its dependencies and their header paths?

petejkim commented Mar 7, 2012

It's due to my lack of familiarity with the code base. Now... how should I get it working with the latest code...?

Owner

alloy commented Mar 9, 2012

Sorry for not getting back to you earlier, I lost track of some emails…

With the current codebase, you can ask the Installer instance for all the dependencies of each individual target with Installer#activated_specifications_for_target(target_definition). And I think you should add the headers to the Sandbox from the TargetInstaller.

@lukeredpath Atm you are more up-to-date on this code than I am, let me know if you think I suggested incorrect locations.

Owner

alloy commented Mar 18, 2012

@petejkim Any updates on this? I’d like to have this in 0.6 :)

Haven't actually got to work on it yet. i'll take a look today

Owner

fabiopelosin commented Mar 9, 2013

Moving to #840

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