On 21 Feb 2013, at 04:03, Jens Alfke wrote:
In general I've found that anything this difficult to just add to a project is probably not worth adding in the first place.
As the author of a number of Cocoa-based libraries, I disagree. In many cases the problem is that Xcode doesn’t have good support for integrating 3rd party code into a project. It’s gotten a little bit better over time, but all too often you still have to mess with build settings like search paths and build phases.
People seem enthused about CocoaPods lately, and it sounds like they fix some issues, but they introduce the major problem that my library’s code is now entirely dependent on your target’s build settings (like prefix headers, compiler modes, warning flags…) As far as I’m concerned, that’s just as big a mess.
I totally agree, that's why with XCode I always go for the simple approach as a backup method. By this I mean, that all the frills. etc of having workspaces and projects within projects is ok as long as it works, when it doesn't, it is a nightmare to try and fix! For this reason I always make sure that at the minimum you can just drag and drop a folder hierarchy into the XCode project, and maybe update the .pch file and/or edit a default file.
That way, the recipient can get going quickly and without fighting a system that is under constant development. If they ever change the adding of files to XCode then we are all doomed anyway!!
I mean if the developers were so lazy/incompetent that that couldn't be bothered to write decent up to date instructions on how to install it then what chance does the code itself have?
It’s not “couldn’t be bothered to write”, it’s “couldn't keep the instructions up to date every time something changes in Xcode”. I’m definitely guilty of that in some of my libraries :-/
I'm sorry if I was rude, said it more for effect than anything else! It would be really nice if you could update it so it just said Broken In XCode Version X in the docs. That's way I'd bypass it without trying to make it work, if it didn't have the fail-safe option above.
My point is that there's plenty of really good code out there that is bypassed because it's hard to get going so it's never seen.
I’ve also found that the ability to write great code, and the ability to write clear docs and set up clean packaging, are not necessarily correlated. Ideally everyone would have both skills, or all projects would be team-ups by people who can contribute their skill, but it’s not always the case.
—Jens
That's true. I was in charge of a third party SDK that we used to license to developers and I became a master at packaging source code/libraries for many platforms, some simple, some more difficult, the bottom line was, if the tools might break the installation, they always give a Hammer and Nail solution.