0.38.0 beta causing Pods compilation error with Extension only methods #3794

hartbit · 2015-07-08T09:16:09Z

I'm using 0.38.0-beta2 and found a potential bug because of target de-duplication #3550.

Problem

One of our projects has a Podfile that is based on this structure:

target "App" do
    pod 'AFNetworking'
end

target "App Extension" do
    pod 'AFNetworking'
end

post_install do |installer|
    installer.pods_project.targets.each do |target|
        if target.name.include?("Extension")
            target.build_configurations.each do |config|
                config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= ['$(inherited)', 'AF_APP_EXTENSIONS=1']
            end
        end
    end
end

The post_install made sure that pod targets that belong to extension targets had the correct defines that AFNetworking requires to pre-process out methods that are not available in extensions. That was necessary because CocoaPods had APPLICATION_EXTENSION_API_ONLY enabled for pod targets that belong to project extension targets.

Since CocoaPods 0.38.0-beta1, AFNetworking pod targets in this project have been de-duplicated, and the one target has APPLICATION_EXTENSION_API_ONLY enabled. This has two serious consequences:

The Pods project fails to compiles because my post_install does not add the AF_APP_EXTENSIONS define to this target.
I could modify my post_install to add the define to all targets that have APPLICATION_EXTENSION_API_ONLY enabled, but this is bad: it means that even in my application target, those methods will have been pre-processed out and I'll never be able to use them.

Solution

In my case, the solution would be for Cocoapods to not de-duplicate AFNetworking. But I'm not sure how Cocoapods can know which dependencies require a define to pre-processor out pieces of code. The only solution I can come up with is if the Podfile syntax allows us to specify certains dependencies not to be de-duplicated.

I know that I can opt-out completely with deduplicate_targets: false, but it's a pity to have to do that for a project as pervasive as AFNetworking.

The text was updated successfully, but these errors were encountered:

neonichu · 2015-07-08T09:23:30Z

Unfortunately, I don't think either solution would work, because toolchain issues with having duplicated frameworks between application and extension targets were one of the reasons for doing the deduplication in the first place. So I think it is really the case that you won't be able to use any APIs beyond APPLICATION_EXTENSION_API_ONLY in your scenario.

segiddins · 2015-07-09T16:37:50Z

@neonichu is correct here.

hartbit · 2015-07-15T16:16:27Z

So I think it is really the case that you won't be able to use any APIs beyond APPLICATION_EXTENSION_API_ONLY in your scenario.

@neonichu I'm sorry but I don't understand 😕 Once 0.38.0 goes live, everybody using AFNetworking and App Extensions (a fair amount of people I would guess) is going to encounter this issue. And if they are using AFNetworking extension-forbidden methods, it's going to make matters worse. What is the solution that the CP team suggests?

neonichu · 2015-07-15T20:59:36Z

@hartbit AFAIK, this is already broken with 0.37, apps couldn't be successfully archived if app and extension both used the same framework, e.g. AFNetworking. This seems to be an Xcode limitation, so the only solution we can recommend for now is to not use any extension unsafe methods and go with the post-install hook which sets AF_APP_EXTENSIONS=1.

rwickliffe · 2015-07-20T17:14:31Z

I just don't think this is true - I, like the original poster, was using 0.37.2 with AFNetworking and a Today widget with a similar post_install and have archived and submitted successfully many times:

post_install do |installer|
    installer.pods_project.targets.each do |target|
        target.build_configurations.each do |config|
            if target.name.include?("Widget-AFNetworking")
                puts "Adding 'AF_APP_EXTENSIONS' macro to #{target.name} #{config.name}"
                config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= ['$(inherited)', 'AF_APP_EXTENSIONS']
            end
            # Disable "Build Active Architecture Only"
            config.build_settings['ONLY_ACTIVE_ARCH'] = 'NO'
        end
    end
end

So the official stance is that this is now broken and there is no workaround in the 0.38.x version of CocoaPods? This is a major issue for me.

neonichu · 2015-07-20T21:01:50Z

@rwickliffe Interesting, can you share your podfile for that project?

Generally, we have seen a lot of people having problems with archiving or even building apps with duplicated frameworks, so the default clearly has to be to deduplicate. You still have the option to opt out of that and get the old behaviour, see https://github.com/CocoaPods/CocoaPods/blob/master/CHANGELOG.md#highlighted-enhancement-that-needs-testing

rwickliffe · 2015-07-20T22:03:56Z

@neonichu You are, of course, correct regarding deduplicate_targets: false - I guess I just was hoping for a solution that wasn't an opt-out for the installation. Thanks for that...

Here is my current podfile - I believe that link_with is leftover from previous project requirements and is likely no longer needed.

source 'https://github.com/CocoaPods/Specs.git'

platform :ios, '8.0'

inhibit_all_warnings!

xcodeproj 'Foo', 'Production' => :release

link_with 'Foo'

def foo_core
    pod 'AFNetworking', '~> 2.0'
    pod 'MMWormhole', '~> 1.0'
    pod 'RNCryptor', '~> 2.2'
    pod 'SSKeychain', '~> 1.0'
    #pod 'Valet', '~> 1.0'
end

target :Foo do
    foo_core
    pod 'Airbrake-iOS', '~> 4.0'
    pod 'BlocksKit', '~> 2.2.2'
    pod 'CocoaLumberjack', '~> 2.0'
    pod 'DZNEmptyDataSet', '~> 1.0'
    pod 'GoogleTagManager', '~> 3.0'
    pod 'MBProgressHUD', '~> 0.8'
    #pod 'OALayoutAnchor', '~> 0.0'
    #pod 'OAStackView', '~> 0.0'
    pod 'OHHTTPStubs', '~> 4.0'
    pod 'OpenTok', '~> 2.0'
    pod 'pop', '~> 1.0'
    pod 'ReactiveCocoa', '~> 2.0'
    pod 'SAMGradientView'
    pod 'SAMLabel'
    pod 'SAMTextView'
end

target :FooTests do
    foo_core
    pod 'Kiwi'
    pod 'XCTAsyncTestCase', :git => 'https://github.com/iheartradio/xctest-additions.git'
end

target :FooWidget do
    foo_core
end

post_install do |installer|
    installer.pods_project.targets.each do |target|
        target.build_configurations.each do |config|
            if target.name.include?("AFNetworking")
                puts "Adding 'AF_APP_EXTENSIONS' macro to #{target.name} #{config.name}"
                config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= ['$(inherited)', 'AF_APP_EXTENSIONS']
            end
            # Disable "Build Active Architecture Only"
            config.build_settings['ONLY_ACTIVE_ARCH'] = 'NO'
        end
    end
end

rwickliffe · 2015-07-20T22:09:45Z

I should also add that the post_install hook above has been updated already for 0.38.0. Prior to today it looked like the following:

post_install do |installer_representation|
    installer_representation.project.targets.each do |target|
        target.build_configurations.each do |config|
            if target.name.include?("FooWidget-AFNetworking")
                puts "Adding 'AF_APP_EXTENSIONS' macro to #{target.name} #{config.name}"
                config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= ['$(inherited)', 'AF_APP_EXTENSIONS']
            end
            # Disable "Build Active Architecture Only"
            config.build_settings['ONLY_ACTIVE_ARCH'] = 'NO'
        end
    end
end

rwickliffe · 2015-07-20T22:46:00Z

@neonichu One last comment that may explain some of my confusion - you mention "duplicated frameworks", but as you can see in the podfile I posted above without use_frameworks!, I have not yet made that transition. Based on the original post, I suspect @hartbit has not either.

neonichu · 2015-07-21T06:34:20Z

@rwickliffe Thanks, I totally overlooked that bit and yes, that explains it. This is why it works for you, the archive/build problems only occur when using frameworks integration.

Maybe we could not deduplicate when using static library integration? @mrackwitz what do you think?

hartbit · 2015-07-22T12:15:02Z

Thanks @rwickliffe for weighting in. Let me see if I can summarise. If I understand correctly, there are two un-related problems:

A first problem with archiving and submitting framework based pod setups, which de-duplication tries to fix
And a second problem when using pods that require two versions (for two sets of pre-processor defines for example), which de-duplication breaks.

The solutions are:

Not doing anything, forcing people like us to set deduplicate_targets: false
Cons: people will still bump into this problem and will have to hunt the web to find out what to do
Cons: seems heavy weight to have a tweak a system-wide setting
Disable de-duplication for static library integration
Cons: does not fix the problem for people using Frameworks integration
Cons: the behaviour will confuse people that are expecting de-duplication to be consistent
Pros: fixes the issue for some people
Provide a Podfile level setting for disabling de-duplication
Cons: people will still bump into this problem and will have to hunt the web to find out what to do
Pros: less heavy-weight than solution 1

What do you think?

neonichu · 2015-07-22T12:20:23Z

Re 2: disabling duplication for framework integration actually doesn't work in practice, as stated above, so I wouldn't count this as a con. Apart from that, this is a good summary of the situation.

Personally, I'm leaning towards 1, because it feels like a special case to me, but we'd obviously need to reconsider if a lot of people actually need to manually opt-out.

josephlord · 2015-07-22T18:13:31Z

I think I may have a workaround by setting use_frameworks only for the extension (which is iOS8 minimum version anyway). This seems to force the deduplication off in this case. I need to do more checking later but I thought it might be useful to suggest quickly in case others want to explore too.

neonichu · 2015-07-22T20:06:28Z

@josephlord True, that's another workaround, thanks for mentioning it.

andi357 · 2015-07-23T11:10:54Z

Just adding use_frameworks! to the extension's target-definition does't really solve the problem for me.
After calling pod_install I still have only one AFNetworking target in the Pods-Project though.

So this doesn't disable the deduplication for the extension target and Xcode is still not able to build my project without using deduplicate_targets: false.

IMO this problem is not a rare 'special case' because it affects every project with an extension that uses AFNetworking.

Edit: I think a Podfile level setting that allows to opt-out the deduplication (like suggested by @hartbit) would be a good way.

neonichu · 2015-07-23T11:23:00Z

@andi357 that sounds like a bug, though. What kind of integration does the one target you end up with use, static library or framework?

andi357 · 2015-07-23T12:14:38Z

@neonichu It's a framework then.

andi357 · 2015-07-23T12:26:01Z

@neonichu And BTW the framework's target is just named AFNetworking, not prefixed with the extension-target's name.

tanis2000 · 2015-08-03T09:19:28Z

Considering that I cannot put use_frameworks! in my widget target as the widget depends on FMDB which in turn depends on SQLite and the header isn't a modular one, what could be a workaround that doesn't involve touching the config.yml file on each developer box (and CI etc...)?

tobihagemann · 2015-08-03T10:30:49Z

Speaking of static library integration. How about a setting to opt-out of deduplication per pod target? I think it's okay to generally deduplicate the targets, but if there are targets that need to be separate, an option would be great. Or is this something that can't be mixed up?

mrackwitz · 2015-08-03T10:40:48Z

@tanis2000: If dependencies use different forms of integration, they should not be deduplicated, but built once as library and once as framework. I think you're bringing up here again a different issue than the one you originally described over in #3550, which was just the same as here originally described by @hartbit or am I missing a point? Feel free to open up a separate issue to elaborate on your new issue.

tanis2000 · 2015-08-03T10:45:12Z

@mrackwitz I'd rather deduplicate than open up a new can of worms trying to have both a static library and a framework when I'm sure that some of the pods I'm already using do not support being compiled into a framework.

For the time being I opted to use the config.yaml solution until something better is available as I cannot stop the development of the app just because of this issue. But that's not really a solution IMHO, it's more of a workaround as it means that all of my projects will be deduplicated, even those that would rather benefit from deduplication.

tobihagemann · 2015-08-03T10:47:21Z

Oh, this is something I didn't realize... you have to set up deduplicate_targets: false in some config file of CocoaPods? And not in the Podfile?

mrackwitz · 2015-08-03T11:03:38Z

@MuscleRumble: Yes, it's a system-wide setting. So your proposal would go beyond that.
In the Podfile you specify dependencies, there is no direct relation (anymore) to actual PodTargets. You
could use a pre_install hook in the Podfile to duplicate selected pod targets.

pre_install do |installer|
    pod_targets = installer.pods_project.pod_targets.flat_map do |pod_target|
        pod_target.name == "foo" ? pod_target.scoped : pod_target
    end
    pod_targets_by_target_definition = pod_targets.group_by(&:target_definition)
    installer.pods_project.aggregate_targets.each do |target|
        target.pod_targets = pod_targets_by_target_definition[target.target_definition]
    end
end

tobihagemann · 2015-08-03T16:42:34Z

If that's possible, that would be great! There are some small typos in your suggestion and I'm not familiar with Ruby, but I tried to fix them and ended up with this (using this documentation):

Edit: Yeah, this isn't fixed at all, see two posts below this one.

pre_install do |installer|
    pod_targets = installer.pod_targets.flat_map do |pod_target|
        pod_target.name == "foo" ? pod_target.scoped : pod_target
    end
    pod_targets_by_target_definition = pod_targets.group_by(&:target_definitions)
    installer.aggregate_targets.each do |target|
        target.pod_targets = pod_targets_by_target_definition[target.target_definition]
    end
end

But I'm getting this error:

NoMethodError - undefined method `each' for nil:NilClass
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/installer.rb:365:in `block in determine_dependency_product_types'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/installer.rb:364:in `each'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/installer.rb:364:in `determine_dependency_product_types'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/installer.rb:106:in `install!'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/command/project.rb:71:in `run_install_with_update'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/command/project.rb:101:in `run'
/Library/Ruby/Gems/2.0.0/gems/claide-0.9.1/lib/claide/command.rb:312:in `run'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/command.rb:48:in `run'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/bin/pod:44:in `<top (required)>'
/usr/bin/pod:23:in `load'
/usr/bin/pod:23:in `<main>'

Any idea?

tanis2000 · 2015-08-03T16:47:17Z

where you reference pod_targets you should actually reference pods_project.targets. I'm not sure that's all you need to do though.

tobihagemann · 2015-08-03T16:50:03Z

~~That's actually one of the things I've fixed. There is no targets in pods_project according to http://www.rubydoc.info/gems/cocoapods/Pod/Project~~

Sorry, as I said I'm not familiar with Ruby and its documentation, haha. Didn't see it inherits from Xcodeproj::Project. Yeah... so... my bad, but still... pods_project seems to be nil, now what? :D

[!] An error occurred while processing the pre-install hook of the Podfile.

undefined method `targets' for nil:NilClass

<redacted>/Podfile:37:in `block (2 levels) in from_ruby'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-core-0.38.2/lib/cocoapods-core/podfile.rb:153:in `call'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-core-0.38.2/lib/cocoapods-core/podfile.rb:153:in `pre_install!'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/installer.rb:736:in `run_podfile_pre_install_hook'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/installer.rb:724:in `block in run_podfile_pre_install_hooks'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/user_interface.rb:140:in `message'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/installer.rb:723:in `run_podfile_pre_install_hooks'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/installer.rb:144:in `block in download_dependencies'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/user_interface.rb:59:in `section'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/installer.rb:141:in `download_dependencies'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/installer.rb:105:in `install!'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/command/project.rb:71:in `run_install_with_update'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/command/project.rb:101:in `run'
/Library/Ruby/Gems/2.0.0/gems/claide-0.9.1/lib/claide/command.rb:312:in `run'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/lib/cocoapods/command.rb:48:in `run'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.38.2/bin/pod:44:in `<top (required)>'
/usr/bin/pod:23:in `load'
/usr/bin/pod:23:in `<main>'

rapinto · 2015-08-04T15:36:46Z

Same problem on my project. I solved it the 'brutal' way by removing the de-duplicate option (deduplicate_targets: false)... I hope another solution will be found.
http://stackoverflow.com/questions/31791365/cocoapod-0-38-0-and-afnetworking-2-5-af-app-extensions-complation-error

mrackwitz · 2015-08-11T09:37:24Z

Sorry, my fault!

pre_install do |installer|
    pod_targets = installer.pod_targets.flat_map do |pod_target|
        pod_target.name == "foo" ? pod_target.scoped : pod_target
    end
    installer.aggregate_targets.each do |aggregate_target|
        aggregate_target.pod_targets = pod_targets.select do |pod_target|
            pod_target.target_definitions.include?(aggregate_target.target_definition)
        end
    end
end

tobihagemann · 2015-08-11T09:50:16Z

Thanks, it works! I think I'm quite happy with this, even if it looks like a hack. xD Should be documented somewhere.

There is btw just a small error in target.pod_targets = pod_targets.select do |pod_target|, it should be aggregate_target in the beginning.

Follow-up question, just to make sure if there is better syntax: How would you do that for multiple pods? So if you have "foo" und "bar"? Is there a more elegant way than (pod_target.name == "foo" || pod_target.name == "bar") ? pod_target.scoped : pod_target? :D

mrackwitz · 2015-08-11T09:57:29Z

@MuscleRumble:

There is btw just a small error in target.pod_targets = pod_targets.select do |pod_target|, it should be aggregate_target in the beginning.

Fixed it above.

How would you do that for multiple pods?

%w(foo bar).include?(pod_target.name)

Should be documented somewhere.

If it's something what turns out to be really needed in general long-term, it should be rather part of the Podfile-DSL.

gistya · 2016-01-12T20:37:21Z

This is still a problem evidently in 0.39.0. I downloaded this project: https://github.com/Ruenzuo/ios-facade-example.git

I've never used cocoapods before, so I did sudo ruby gem install cocoapods. Then I cd into /usr/local/src/ios-facade-example/ and ran the pod install.

First it says "project" cannot be found and another thread said to change this to "pods_project". So I did that.

Then it dies on this error:

[!] An error occurred while processing the post-install hook of the Podfile.

undefined method `build_configurations' for nil:NilClass

/Users/jjj/Documents/dev/ios-facade-example/Podfile:9:in `block (2 levels) in from_ruby'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-core-0.39.0/lib/cocoapods-core/podfile.rb:170:in `call'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-core-0.39.0/lib/cocoapods-core/podfile.rb:170:in `post_install!'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.39.0/lib/cocoapods/installer.rb:806:in `run_podfile_post_install_hook'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.39.0/lib/cocoapods/installer.rb:794:in `block in run_podfile_post_install_hooks'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.39.0/lib/cocoapods/user_interface.rb:140:in `message'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.39.0/lib/cocoapods/installer.rb:793:in `run_podfile_post_install_hooks'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.39.0/lib/cocoapods/installer.rb:158:in `block in generate_pods_project'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.39.0/lib/cocoapods/user_interface.rb:59:in `section'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.39.0/lib/cocoapods/installer.rb:153:in `generate_pods_project'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.39.0/lib/cocoapods/installer.rb:111:in `install!'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.39.0/lib/cocoapods/command/project.rb:71:in `run_install_with_update'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.39.0/lib/cocoapods/command/project.rb:101:in `run'
/Library/Ruby/Gems/2.0.0/gems/claide-0.9.1/lib/claide/command.rb:312:in `run'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.39.0/lib/cocoapods/command.rb:47:in `run'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-0.39.0/bin/pod:44:in `<top (required)>'
/usr/local/bin/pod:23:in `load'
/usr/local/bin/pod:23:in `<main>'

Yeah so. It's broken. You guys, I have to say real bluntly, because I've never used cocoapods before, but isn't the whole point of cocoapods, to avoid crap like this?

I mean honestly, if you can't manage to make it retain backwards compatibility with older projects then what are you even doing? Why can't it auto-detect when there is an error like this using proper exception handling, and then take some alternate steps to resolve the issue internally in the code? Rather than just break everyone's projects?

If it's going to be like this then people might as well not even use cocoapods, because now the dependencies must be manually installed since cocoapods is broken for the project.

BTW -- Yes, I was able to fix it by going into ~/.cocoapods/config.yaml and adding "deduplicate_targets: false" but, my point is, should not have to do that. The software should be able to automatically set deduplicate_targets: false anytime it encounters this exception, the re-run the command and succeed. So people don't have to google the error and sift through 10 github comment threads to fix it.

rwickliffe · 2016-01-12T21:21:19Z

This worked for me for that linked project, which is 2 years old:

platform :ios, '7.0'
pod 'AFNetworking', '~> 2.0'
pod 'TMCache', '~> 1.2.0'
pod 'MagicalRecord', '~> 2.2'
pod 'Mantle', '~> 1.3.1'
pod 'CocoaLumberjack', '~> 1.7.0'
post_install do |installer|
  target = installer.pods_project.targets.find{|t| t.to_s == "MagicalRecord"}
    target.build_configurations.each do |config|
        s = config.build_settings['GCC_PREPROCESSOR_DEFINITIONS']
        s = [ '$(inherited)' ] if s == nil;
        s.push('MR_ENABLE_ACTIVE_RECORD_LOGGING=0') if config.to_s == "Debug";
        config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] = s
    end
end

Note that this also required an update to AFNetworking:
pod update AFNetworking

This will get you to the point that you can see all the additional warnings you'd expect from an example project that is 2 years old.

From semver.org:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

tobihagemann · 2016-05-11T19:59:04Z

@mrackwitz Your pre-install hook worked until some recent 1.0.0 update (I believe 1.0.0.beta.3 still worked, but I'm not 100% certain). I'm now getting the error:

NoMethodError - undefined method `project' for nil:NilClass
/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.2.0/gems/xcodeproj-1.0.0/lib/xcodeproj/project/object/native_target.rb:225:in `add_dependency'
/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.2.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:670:in `block (3 levels) in set_target_dependencies'
/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.2.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:668:in `each'
/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.2.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:668:in `block (2 levels) in set_target_dependencies'
/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.2.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:654:in `each'
/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.2.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:654:in `block in set_target_dependencies'
/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.2.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:649:in `each'
/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.2.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:649:in `set_target_dependencies'
/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.2.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:171:in `block in generate_pods_project'
/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.2.0/gems/cocoapods-1.0.0/lib/cocoapods/user_interface.rb:63:in `section'
/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.2.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:167:in `generate_pods_project'
/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.2.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:119:in `install!'
/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.2.0/gems/cocoapods-1.0.0/lib/cocoapods/command/install.rb:37:in `run'
/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.2.0/gems/claide-1.0.0/lib/claide/command.rb:334:in `run'
/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.2.0/gems/cocoapods-1.0.0/lib/cocoapods/command.rb:50:in `run'
/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.2.0/gems/cocoapods-1.0.0/bin/pod:55:in `<top (required)>'
/Applications/CocoaPods.app/Contents/Resources/bundle/bin/pod:23:in `load'
/Applications/CocoaPods.app/Contents/Resources/bundle/bin/pod:23:in `<main>'

Any idea how to solve this? Maybe some variable names have changed?

Edit: Quick reminder. This is the pre-install hook I'm referring to:

pre_install do |installer|
    pod_targets = installer.pod_targets.flat_map do |pod_target|
        pod_target.name == "foo" ? pod_target.scoped : pod_target
    end
    installer.aggregate_targets.each do |aggregate_target|
        aggregate_target.pod_targets = pod_targets.select do |pod_target|
            pod_target.target_definitions.include?(aggregate_target.target_definition)
        end
    end
end

Edit2: It's important to me that I'm able to deactivate deduplication of specific Pods, because I need to set some preprocessor macros on App Extension targets. If there's a cleaner syntax for it or if I have to deduplicate all Pods, I guess I could do so, even though it's not as elegant as before.

cerupcat · 2016-08-18T20:16:13Z

@tobihagemann did you ever fix your error? I have the same error.

NoMethodError - undefined methodproject' for nil:NilClass`

tobihagemann · 2016-08-18T21:41:51Z

Unfortunately, I haven't. The method I've used won't be supported anymore, that's why I don't know if a fix even exists. You have to use subspecs now, as suggested here: #5373 (comment)

Didn't get the chance to try subspecs out myself yet. It's kind of sad, I'm still using 1.0.0.beta.3. 😅 I didn't lie that I think using subspecs is the way to go, but I didn't mange to find the time and nerves to actually change my setup! 😉

segiddins closed this as completed Jul 9, 2015

This was referenced Aug 3, 2015

Target Deduplication and App Extensions #3951

Closed

Deduplicate pod targets #3550

Merged

tobihagemann mentioned this issue Aug 25, 2015

How to use SVProgressHUD in an App Extension? SVProgressHUD/SVProgressHUD#432

Closed

tobihagemann mentioned this issue May 17, 2016

Opt-out of deduplication per pod target #5343

Closed

1 task

0.38.0 beta causing Pods compilation error with Extension only methods #3794

0.38.0 beta causing Pods compilation error with Extension only methods #3794

Comments

hartbit commented Jul 8, 2015

Problem

Solution

neonichu commented Jul 8, 2015

segiddins commented Jul 9, 2015

hartbit commented Jul 15, 2015

neonichu commented Jul 15, 2015

rwickliffe commented Jul 20, 2015

neonichu commented Jul 20, 2015

rwickliffe commented Jul 20, 2015

rwickliffe commented Jul 20, 2015

rwickliffe commented Jul 20, 2015

neonichu commented Jul 21, 2015

hartbit commented Jul 22, 2015

neonichu commented Jul 22, 2015

josephlord commented Jul 22, 2015

neonichu commented Jul 22, 2015

andi357 commented Jul 23, 2015

neonichu commented Jul 23, 2015

andi357 commented Jul 23, 2015

andi357 commented Jul 23, 2015

tanis2000 commented Aug 3, 2015

tobihagemann commented Aug 3, 2015

mrackwitz commented Aug 3, 2015

tanis2000 commented Aug 3, 2015

tobihagemann commented Aug 3, 2015

mrackwitz commented Aug 3, 2015

tobihagemann commented Aug 3, 2015

tanis2000 commented Aug 3, 2015

tobihagemann commented Aug 3, 2015

rapinto commented Aug 4, 2015

mrackwitz commented Aug 11, 2015

tobihagemann commented Aug 11, 2015

mrackwitz commented Aug 11, 2015

gistya commented Jan 12, 2016

rwickliffe commented Jan 12, 2016

tobihagemann commented May 11, 2016 • edited

cerupcat commented Aug 18, 2016

tobihagemann commented Aug 18, 2016

tobihagemann commented May 11, 2016 •

edited