Package the source code into a static library

[zoul]

I think the sources are easier to use when packaged into an Xcode project with a library target. (My primary target is iOS. If there are people using JSONKit on desktop Macs, it should be trivial to add a framework target to the project.)

One benefit is that you can bundle the tests along with the library, which should make development easier. The tests are currently run whenever the library gets built for the Simulator. (I have added one example test to the project to make it clear how things work.)

Another plus is that you don’t have to monkey around with ARC settings. If you have a project that uses ARC, you can link against the library that uses manual memory management just fine.

And a third advantage – that made me fork your code in the first place – is deployment in projects where the JSONKit code is used more than once. I have two libraries that both bundle the naked JSONKit sources and obviously I get a linker complaining about duplicate symbols. This should be easier to solve with a static library.

There are no drawbacks for people who don’t need the Xcode project, they can grab the naked sources as usually.

[zoul]

I have written two blog posts (one, two) about static libraries and code reuse in Xcode; these might argue in better detail why static libraries are more useful than naked source files.

[MSchmidt]

+1 especially for compatibility with ARC and non-ARC projects!

[ghost]

ARC is a satan's abomination, if you want a static lib just use your lazy tiny fingers and write a simple makefile, this kind of request, that's just insane.

[MSchmidt]

Whatever your opinion is on ARC, it would be a good thing for JSONKit to support both kinds of projects.

[ghost]

if you read carefully the documentation about ARC there is no issue mixing both until you do the right thing, tagging your code with insane qualifiers which the compiler will just parse to put it back the perfect way it was..., just an insane man could have invented this stupidity, moreover developers want memory control not garbage at large, they want to see it in their code, if you disagree you should move back to scripting languages such as java or c#, the toys for the kids.

[zoul]

If you don’t find the feature useful, please feel free to ignore this pull request.

[jonsterling]

I find @Cucurbita's ramblings rather difficult to decipher, though I can at least determine that they're quite unproductive. Here's my take:

If your project uses ARC, either package your own static library or specify that those particular files should not built with ARC (this is possible in Xcode's Build Phases).

In general, I prefer all my dependencies in static libraries, so I definitely see where you are coming from. However, I also happen to think it's really cool that JSONKit is distributed as minimally as it is. In fact, I think that's one of its more attractive attributes.

[escoz]

+1 for static library. Clear separation between library code and application code makes it much easier to keep track of changes while still making it easy for people to stay in sync with project changes.

Congrats to @jonsterling for being so professional regarding @Cucurbita's comment.

[ghost]

@jonsterling shame is always a good motivation for redemption

[zoul]

OK, there’s obviously little motivation to merge.