Demo project not compiling

[ghost]

Hi,

This issue was resolved because the following output was generated.

Robs-iMac:Example robertnash$ pod install
Analyzing dependencies
Downloading dependencies
Installing ObjectBox (0.5.2)
Installing Sourcery (0.15.0)
Generating Pods project
Integrating client project
Sending stats
Pod installation complete! There is 1 dependency from the Podfile and 2 total pods installed.

However, the project doesn't run.

error: /Users/robertnash/Downloads/objectbox-swift-master/Example/Pods/Pods/Target Support Files/Pods-NotesExample-iOS/Pods-NotesExample-iOS.debug.xcconfig: unable to open file (in target "NotesExample-iOS" in project "NotesExample") (in target 'NotesExample-iOS')

I have performed a clean build and I have purged the Xcode build folder but rebuilding produces the same error.

Side-note: I don't have a great relationship with the Cocapods team.

[ghost]

Xcode: Version 10.1 (10B61)

Robs-iMac:Example robertnash$ brew info cocoapods
cocoapods: stable 1.5.3 (bottled)
Dependency manager for Cocoa projects
https://cocoapods.org/
/usr/local/Cellar/cocoapods/1.5.3 (8,923 files, 13.2MB) *
  Poured from bottle on 2018-08-09 at 18:31:04
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/cocoapods.rb
==> Analytics
install: 11,912 (30 days), 35,769 (90 days), 143,411 (365 days)
install_on_request: 11,804 (30 days), 35,347 (90 days), 138,918 (365 days)
build_error: 0 (30 days)

[uli-objectbox]

Did you run the Pods/ObjectBox/setup.rb script as mentioned in the Readme? What did it output?

[uli-objectbox]

That's the same versions of Xcode, Cocoapods, ObjectBox and Sourcery I'm running, though I installed CocoaPods via gem install cocoapods. Maybe there's a difference between those two builds of CocoaPods?

I'm especially surprised that your path says /Pods/Pods/. That should only be one Pods folder. A quick fix for now would be to correct the paths using Xcode's inspector to point to the files in the Pods folder again.

Another thing to try would be to delete the Pods group from the project, then pod install again, that might force CocoaPods to re-add those references, and maybe it will do them right this time.

Have you set up any custom paths for Xcode to build to? Under Xcode > Preferences > Locations or under File > Workspace Settings... ? For me those are all Default, and the latter use the new build setting and the shared setting for the build system.

Do you do any Ruby development? Did you maybe update your Ruby (or switch it out using RVM)? If yes, can you switch back to the system-supplied Ruby?

[ghost]

Hi @uli-objectbox

Thanks for getting back to me.

Yes, I have done some minor development with Jekyll checkout the second paragraph here regarding the painful installation attempt.

No I totally missed the ruby script suggestion. This is what happened when I tried to run it.

Robs-MBP:Example robertnash$ Pods/ObjectBox/setup.rb
Traceback (most recent call last):
	2: from Pods/ObjectBox/setup.rb:3:in `<main>'
	1: from /usr/local/Cellar/ruby/2.5.1/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
/usr/local/Cellar/ruby/2.5.1/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot load such file -- xcodeproj (LoadError)

I think I might call it a day at this point. I think this is specific to me only. I don't enjoy playing around with ruby / cocoapods to run iOS projects because it always takes days and the time of professional ruby developers.

So I would rather not waste your time and expertise my friend. Thanks for your time so far.

[uli-objectbox]

Rob, that means you installed CocoaPods in another Ruby than what comes with macOS by default. We assume that people install Cocoapods using the system's main Ruby, and assume dependencies of Ruby like the xcodeproj extension are already there. You could probably just run gem install xcodeproj to install that dependency of the script.

Alternately, uninstalling your Brew copy of Ruby 2.5.1 and installing Cocoapods via the system Ruby 2.3.7's gem install cocoapods would also work. We're basically assuming that you installed CocoaPods in your main Ruby, which is why some things don't work for you (We don't have a way to detect that there is a second Ruby installation and that we should use that instead, after all).

[greenrobot]

@rob-nash Also, thank you for your thoughts on CocoaPods. We have noted the complexity of Cocoapods, Ruby and their "dependency hell". We'll keep a close eye on that and pay attention on further feedback from users.

[ghost]

@uli-objectbox totally agree. I once worked alongside a team member who found all of this very easy because guess what? He had a long history as a ruby developer before he became full time iOS.

It's not uncommon for iOS devs to come from some other platform and most of the developers I've met over the last 10 years are always willing to roll up their sleeves and 'give it a go'.

But in my old age I'm losing steam I think. I can't really be bothered to step out of my area of expertise for several hours to run a demo App. You know what I mean? Full respect to you guys; my argument is mostly with cocoapods.

Typically the problem is simple. Like you said, it's just a ruby environment that needs switching. But if you don't know then...you don't know. And it always seems to be a new unique problem each time.

Often I need to hold someone's hand on stackoverflow to get past these barriers and I'm trying to make the case that there should be no barrier at all.

I could tell you many stories where the client I'm working for want's something done by TOMORROW and my project doesn't compile because cocoapods is demanding some expert ruby knowledge.

Anyway, rant over. It was nice speaking with you. Feel free to share your frustrations with the cocoapods team. Maybe if we make enough noise, positive change will happen with them. I get the impression they don't see it as an issue.

And I kinda want iOS developers to know that spending hours doing this kind of stuff is not ok! A lot of iOS dev's seem to think it's a normal part of their day. But it shouldn't be.

[uli-objectbox]

@rob-nash If you're more comfortable working with Xcode manually, you could also just download the lastest release from the Releases section here on Github, add the framework in it to your project, and follow the directions at https://swift.objectbox.io/advanced/sourcery to set up the Sourcery build phase and add the generated files to your project.

When it works, the CocoaPods way is just easier than doing all of this by hand, and that documentation is still a work in progress, so we haven't yet advertised that method much. We're hoping to eventually make other packaging mechanisms (like Carthage, SPM and manually setting stuff up) easier in the future, but it will take some more time.

[ghost]

Thanks I’ll check it out. Take a look at my project here on Github named Records, which uses sourcery, to see how I setup the docs to align with Carthage if that helps. Peace.