neonichu
commented
8 years ago 🤔 shouldn't RubyGems just take care of this and allow you to have multiple versions of Xcodeproj installed?
Open jcampbell05 opened 8 years ago
neonichu
commented
8 years ago 🤔 shouldn't RubyGems just take care of this and allow you to have multiple versions of Xcodeproj installed?
Not sure if this is a stupid Ideas but I was wondering if we should split out the default build settings and plist bindings into a seperate
xcode-supportgem for Xcodeproj ?Why?
Right now if you want to work with the latest Xcode you have to have the latest Xcodeproj, this causes problems.
My tool Xcake uses Xcodeproj to generate Project files, if you use an older version of Cocoapods then the Xcodeproj is also an older version this means two things:
The only way around this is to upgrade my CocoaPods version to 1.0 and thus uses the new Xcodeproj however I can’t do this just yet due to all the changes I need to absorb which has forced me to add these workarounds into Xcake directly. Also this wouldn’t help as the build settings I needed are still in master for Xcodeproj, which I’m nervous about using in production.
Having a seperate gem which could have the latest recommended Xcode build settings and the latest bindings for the latest xcode would be awesome. Not only could other Ruby based tools share these. But if I have a project that needs an older version of CocoaPods and Xcodeproj then I could use the latest build settings and have my project still written out in the Plist format even if Xcodeproj itself was written against an older version of Xcode.
This puts less work on me as a user and a tool writer - I can use the most up to date Xcode support by simply upgrading the
xcode-supprotwithout having to upgrade my entire toolchain. Xcodeproj is then mainly focused on writing the project file itself and this other gem is focused on the actual default xcode build settings and integration of xcode API (aka the Plist writing).What do you guys think ?