Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Static Library Target #90

Closed
myell0w opened this Issue Nov 30, 2011 · 15 comments

Comments

Projects
None yet
5 participants
Contributor

myell0w commented Nov 30, 2011

Are you willing to convert MagicalRecord to a static library target?
I would happily send a pull request, if you wish.

@ghost

ghost commented Nov 30, 2011

I'm not sure what the benefits are to everyone...
Could you elaborate as to why you (or anyone) would want to do this?
I'm truly curious as to the benefits, or hindrances...

There are some things in the source that are compiled out when they're disabled (like shorthand methods)...so keep that in mind :)

Thanks,
Saul

Saul Mora
Founding Panda
saul@magicalpanda.com

On Nov 30, 2011, at 3:10 AM, Matthias Tretter wrote:

Are you willing to convert MagicalRecord to a static library target?
I would happily send a pull request, if you wish.


Reply to this email directly or view it on GitHub:
#90

Contributor

tonyarnold commented Dec 1, 2011

The arguments I have seen for the static library approach relate to repeatable behaviour — if an app (or a group of apps) all use a statically-compiled library as opposed to including the source code directly, then the library can be a "known entity". Compilers and SDKs change, but in theory you could just keep using the same library in each of your projects and know that you're going to get pretty identical behaviour between your apps.

Personally/professionally I don't think this is as great an advantage as it's made out to be, nor is it guaranteed — but quite a few iOS developers that I trust and respect use this approach in their projects. If @myell0w is willing to contribute the pull request, it's probably worthwhile looking into — as long as it doesn't interfere with the current approach of just including MR's source in projects.

I'd be interested in @myell0w's take on this issue — maybe there's something else that I'm unaware of.

Contributor

myell0w commented Dec 2, 2011

I do have some points that speak for a static library target, other than that it's considered best-pracice.

First of all a static library-target is more like a black-box and represents a standalone-functionality. If the project has issues, they show up under the target the issues belong to and not under the App-target: https://skitch.com/myellow/gp859/xcode. Furthermore the mixing between ARC and non-ARC code is easier when using static libraries, since you don't have to specify if the target uses ARC or not. Another issue just recently hit me with MagicalRecord: If files get removed/added you have to re-add them to your Xcode project, whereby you don't have to worry about this issue when using a static library. The last but not least issue is that you don't have to recompile a static library target if you change files in your project.

Additionaly the current approach of integrating the files directly in your App still can be used, so from my point of view there would be no point against a static library target and my offer still exists :)

Contributor

myell0w commented Dec 3, 2011

I have to correct myself: Of course you have to specify whether the library uses ARC or not, but you only have to specify it for the library as a whole and not for each file independently.

@ghost

ghost commented Dec 11, 2011

So, my take on this is, as long as I can still use the Source Code approach, I'm ok with having a separate target in the project that dumps out a static library. Though, I would also argue, that if you're going that far, why not create a Framework so that the proper headers are also included in the Framework bundle, rather than having to do things in multiple, error prone stages?

dodikk commented Dec 13, 2011

Static library approach benefits when multiple sub projects (custom libraries that ).
For example, both the Facebook SDK and your executable are both using some XML or JSON library.

The same case may apply to the MagicalRecord.

why not create a Framework
Most likely, it's because xCode has no built-in target for this purpose. And some additional scripting is required from the developer.

P.S. Yes, I do know about this template https://github.com/kstenerud/iOS-Universal-Framework

Contributor

tonyxiao commented Jan 3, 2012

Another benefit of static binary / framework is that it is much easier to keep MagicalRecord source code up to date when they sit inside their own repo and can be readily pulled from github.

dodikk commented Jan 3, 2012

If you don't like copy-paste code reuse either - please consider our fork at https://github.com/EmbeddedSources/MagicalRecord

We have both a static library and a framework target.

P.S. just sent a pull request with those changes.

Contributor

tonyxiao commented Jan 3, 2012

I'm trying to understand, why do you have a MagicalRecordLibrary.xcodeproj as a subproject of the main MagicalRecord.xcodeproj? What's the rationale here? Why not just create framework / static binary targets inside the main project itself?

dodikk commented Jan 4, 2012

The short answer is

"your library has less dependencies". You can pick up and use just the library without having to include the whole bunch of demos and examples.

More detailed

I consider a target being just another artifact for a single thing.
For example, you may release a library both in a static (libXXX.a) and dynamic (XXX.dylib / libXXX.so ) forms.
I use targets for such sort of tasks because they all do share the same code.

Moreover, both build and link time project dependencies work just fine for subprojects.

Here is my rule

" ONE thing - ONE project "

dodikk commented Jan 4, 2012

Dear tonyxiao .
I hope my post above makes sense.

Contributor

tonyxiao commented Jan 13, 2012

Actually I just realized, the perfect solution to the problem I posted on Jan 3 is to use git submodule, it keeps things properly in sync perfectly! Far as I'm concerned this reduces the value of a static library target tremendously, I don't really care to compile from source.

dodikk commented Jan 24, 2012

I do care, however.

@ghost ghost assigned tonyarnold Dec 14, 2012

Contributor

tonyarnold commented Dec 14, 2012

I'll look into both a static library, and a framework for OS X in the next major release of MR.

Contributor

tonyarnold commented Apr 8, 2014

MagicalRecord will support a static library for iOS, and a framework for OS X in version 3.0. Thanks for your patience.

@tonyarnold tonyarnold closed this Apr 8, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment