Open Radar

 
01-Aug-2012 03:57 AM Andrew Crawford:
Summary:

Code re-use is a good thing.  I'd like to be able to use lots of libraries in my code, and to develop more libraries for others to use.  The primary barrier to putting code in a library for re-use is XCode.

My workflow looks like this:

1.  Create a git repository for the library
2.  Add the library as a submodule for my project's repository
3.  Convince Xcode to build and link against the subproject

Step 3 is really hard.  It commonly involves configuring build settings, working around the -all_load issue, adding a target dependency, linking against the library's product, adding additional dynamic links for frameworks that the library needs, and more.  Heaven help you if your library has dependencies, and you have to go install those.   And those dependencies step on the symbols of another libraries' dependencies.

Look at KIF.  They recommend you create an additional target as part of the installation: https://github.com/square/KIF/

AFNetworking requires you to disable a bunch of ARC stuff: https://github.com/AFNetworking/AFNetworking/wiki/Getting-Started-with-AFNetworking

CorePlot isn't really sure how you should install it: http://code.google.com/p/core-plot/wiki/UsingCorePlotInApplications

These are libraries that people actually use, and they are hard to install.  If libraries are hard to install, then nobody is going to make libraries.  And nobody will use libraries.  And if the easiest way to get a library installed is to drag some files around (which is a very common suggestion), then the very few people who use libraries will not submit pull requests or track updates, and libraries will not get better.

All that needs to happen to fix this is a text field in XCode (or even a third-party tool) where I can paste a git repository URL, that repository is added as a submodule or subtree to my current repository, and somehow the linking and framework and build settings stuff "just works", and I can get pretty green lights in the organizer window about whether my submodules are up to date.  Maybe the required configuration changes is specified in a recipe by the library.

Here's why I can't implement that tool myself: I can't convince XCode to add a project to a workspace or add a build phase or add some preprocessor macros or link against a static library in an automated way, without a LOT of brittle hackery.  

Ideally I'd try and manipulate the project with Applescript, but unfortunately Applescript and XCode is horribly broken: http://the.darktable.com/post/17700178147/modifying-an-xcode-project-with-applescript-is

I tried poking around a bit with editing the pbxproj file directly.  Performing some action is XCode, diffing the before and after, and trying to reverse-engineer what to do.  But this is complicated with workspaces, and there is a lot of undocumented stuff in there (what is a PBXReferenceProxy and why do I care?) and obviously this will break in the future.

CocoaPods is trying to solve this problem, but they are really hampered by how hacky the pbxproj editing is.  And every time I try to go in and extend it, something breaks, and I don't know what it is or why, because pbxproj is completely undocumented.

Please give me a recipe format so that I can make my libraries installable with a click.  Or, give me an API that actually works so I can manipulate the workspace graph and install the library myself. 


Steps to Reproduce:

Expected Results:

Actual Results:

Regression:

Notes: