Cocoapods: Trouble building target in debug configuration after update to 1.0

[DarkInsight85]

• [x] I've read and understood the *CONTRIBUTING guidelines and have done my best effort to follow.
  

  Report

After update CocoaPods to 1.0, project can no longer be build in debug configuration. Other configurations still works; in fact, I have even archived and submitted to app store.

What did you do?

Update CocoaPods: sudo gem install cocoapods

• Updated pods: pod update
• Archived project, works fine
• Removed 'Embed Pod Frameworks' from my WatchKit extension and Today extension targets, following instruction from here
• Submitted to app store, works fine
• Next day, tried to debug the project, ran into error: "'Mantle/MTLJSONAdapter.h' file not found" for my WatchKit extension and Today extension targets
• Tried to 'pod update', 'pod install', both doesn't work
• Tried 'pod deintegrate' followed by 'pod install', still doesn't work
• Checked from TestFlight the build I have uploaded to iTunesConnect the previous day, the build works fine, I just couldn't debug the same project on Xcode

What did you expected to happen?

• Able to debug my project

  What happened instead?

• Ran into error: "'Mantle/MTLJSONAdapter.h' file not found" for my WatchKit extension and Today extension targets

  CocoaPods Environment

Stack

   CocoaPods : 1.0.0
        Ruby : ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin15]
    RubyGems : 2.0.14.1
        Host : Mac OS X 10.11.4 (15E65)
       Xcode : 7.3.1 (7D1014)
         Git : git version 2.7.4 (Apple Git-66)
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ ace7f23e78aa54d26f3637319f9814bc52c2a570

Installation Source

Executable Path: /usr/local/bin/pod

Plugins

cocoapods-deintegrate : 1.0.0
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.0.0
cocoapods-trunk       : 1.0.0
cocoapods-try         : 1.0.0

Podfile

# Uncomment this line to define a global platform for your project
platform :ios, "8.0"
use_frameworks!
inhibit_all_warnings!

target "CallLevels" do
    pod 'AFNetworking', '~> 3.0'
    pod 'Crashlytics'
    pod 'EGOCache', '~> 2.1'
    pod 'Fabric'
    pod 'Lockbox', '~> 2.1'
    pod 'Mantle', '~> 2.0'
    pod 'AppsFlyer-SDK'
    pod 'Branch'
    pod 'Charts'
    pod 'DGElasticPullToRefresh', '~> 1.0'
    pod 'FBSDKCoreKit',  '~>4.8'
    pod 'FBSDKLoginKit', '~>4.8'
    pod 'FBSDKShareKit', '~>4.8'
    pod 'Google/Analytics'
    pod 'GoogleIDFASupport'
    pod 'HTMLReader', '~> 0.9'
    pod 'iRate', '~> 1.11'
    pod 'M13Checkbox'
    pod 'Mixpanel'
    pod 'Parse', '~> 1.11'
    pod 'pop', '~> 1.0'
    pod 'SVProgressHUD', '~> 1.1.3'
    pod 'SVPullToRefresh', '~> 0.4'
    pod 'SWTableViewCell', '~> 0.3'
    pod 'TPKeyboardAvoiding', '~> 1.2'
    pod 'ViewUtils', '~> 1.1'
end

target "CallLevelsTests" do

end

target "CallLevels WatchKit Extension" do
    pod 'AFNetworking', '~> 3.0'
    pod 'Crashlytics'
    pod 'EGOCache', '~> 2.1'
    pod 'Fabric'
    pod 'Lockbox', '~> 2.1'
    pod 'Mantle', '~> 2.0'
end

target "CallLevels Widget" do
    pod 'AFNetworking', '~> 3.0'
    pod 'Crashlytics'
    pod 'EGOCache', '~> 2.1'
    pod 'Fabric'
    pod 'Lockbox', '~> 2.1'
    pod 'Mantle', '~> 2.0'
end

[segiddins]

@benasher44 want to tack this onto the list of extension issues?

[Coeur]

@DarkInsight85, you could try this syntax:

#import <MTLJSONAdapter.h>

[orta]

( also worth seeing if @import Framework; fixes it too )

[dstranz]

I have similar problem probably - I'm not able to build project with Debug configuration after adding new file to Development Pods. It ends up with

ld: symbol(s) not found for architecture x86_64
  "_OBJC_CLASS_$_AdLoader", referenced from:
***
clang: error: linker command failed with exit code 1 (use -v to see invocation)

When I change configuration to Release, it builds and run without problem.

Changing import to
#import <AdLoader.h>
doesn't help.

Pod install, pod deintegrate and pod install and other things doesn't help.

[segiddins]

@dstranz please share a project that reproduces the issue. Thanks!

[dstranz]

@segiddins I will try to reproduce it on example project.

[benasher44]

@segiddins I'm not sure that the fix for the issue I'm working on is going to have any affect on header search paths, but I'll be sure to ping on this issue as well when I have a working branch ready, just in case

[Coeur]

@dstranz, in case you have trouble to reproduce the issue on a different project, try to delete the ~/Library/Developer/Xcode/DerivedData folder.

[proskd]

@DarkInsight85 i'm also seeing the same issue with Mantle. What's weird is I created a brand new sample project and used basically the exact podfile we're currently using in our main project and it builds just fine, which makes no sense to me at all. I've compared the build settings between our main project and the sample and don't see any meaningful difference. I also tried deleting the DerivedData folder but to no avail.

Would be really curious to know if anyone actually figures out what the underlying issue here really is.

EDIT: apparently posting here on github.com was the solution. Immediately after I posted this, I tried again. Xcode crashed, then I reopened the project, ran pod install, and it works. makes literally no sense to me. Not sure if this helps anyone else seeing the same problem, but I guess your goal should be to try everything and then get Xcode to crash?

[Coeur]

Maybe you didn't close Xcode while deleting the DerivedData, or you didn't empty the trash before reopening Xcode. Either way, good news it got fixed for you, @proskd. I had the same kind of issues a few months ago with the beta releases, so I'm happy to help people moving to the stable release.

[proskd]

@Coeur yeah it's certainly possible that's what happened.

[dstranz]

@Coeur rm -rf ~/Library/Developer/Xcode/DerivedData helped! Thank you!

[DarkInsight85]

Thanks! Can confirm remove DerivedData works!

[DarkInsight85]

Should I close this issue?

[Coeur]

@DarkInsight85, yes please.