Closed NinjaLikesCheez closed 7 years ago
Tatsh
commented
7 years ago What's with the new branch? master already has the project setup? It needs some fixes.
Also with regard to type warnings (and other warnings), we should not be fixing any third party code. That means optool, MiniZip, etc. I made MiniZip a target so it hopefully gets ignored.
Tatsh
commented
7 years ago Also do we want to use Carthage or Cocoapods for dependencies? Or submodules? Carthage gives better control via Git hashes, while Cocoapods is purely dependent on the owner of the project posting a new release to Cocoapods.
NinjaLikesCheez
commented
7 years ago I pushed to a new branch just incase I broke a massive amount of things (very likely with my luck).
I only had to add a declaration to ZipArchive.h (which you're right I shouldn't have) however I couldn't get it to build without importing Foundation - this was done before via a precompiled header I believe, which is maybe why it wasn't an issue until now.
On the dependancies side, I've only ever used Cocoapods years ago - so I will leave that judgement to someone with a better knowledge of which is better and why - although I think I would lean towards Carthage just because it's unintrusive. While on dependancies I want to cut GBCLI sometime soon, we don't need it so we shouldn't have it.
Tatsh
commented
7 years ago Very open to minimising the dependencies as they aren't really separated out for now. We link with z (zip) but can we use those functions directly in the wrapping Objective-C class instead of MiniZip? Using stuff that is built-in to iOS = great. There's also probably tons of private stuff that would reduce our deps, however I do not expect to find a command line parser.
NinjaLikesCheez
commented
7 years ago Agreed. The cleaner the better. If only argp was available, that would solve gbcli. zip has always been a pain, but there's got to be a better solution than using a (now) rather old wrapper.
Tatsh
commented
7 years ago Have to look at the private header dumps for stuff and consider stability of such things. We go down to iOS 8.0 now. We can actually get rid of the MI < iOS 7 code and the warning that pops up on launch should say that Clutch requires iOS 8.0.
By the way, if you have any success whatsoever debugging with Xcode (pass argument like -d 1) let me know. I want to know what trick you did. I can't get this to work and it would be really useful and I don't want to use the remote LLDB debugger if I can get one directly connected into Xcode. I want to solve that Alamofire framework issue #147 among others like #144. Live debugging would make this much easier.
When I do Product -> Run.
Tatsh
commented
7 years ago By the way, we'll probably end up keeping MiniZip anyway. I just checked private headers for iOS 8.0 and there is no private stuff Apple has in iOS that will create zip files in the same easy way that the wrapper does. That being said, could switch to a more modern wrapper via dependency but I don't see a real reason to do so yet.
NinjaLikesCheez
commented
7 years ago I'm going to go ahead and remove the xcode-building branch as master already has the changes, in a better form (and close this).
Letting xcode handle building for target apps means we get nice IDE features if we so choose. Make it easier to download, open, and build in an expected way on mac OS.
Needs: Updating README and other references re: building option Some more refactoring to make some changes more complete (removing stuff out of pch into constants/configuration, build paths and options, fix or suppress of build warnings) Testing