Re: Organizing .h and .m files.
Re: Organizing .h and .m files.
- Subject: Re: Organizing .h and .m files.
- From: Greg Guerin <email@hidden>
- Date: Fri, 5 Oct 2007 11:41:32 -0700
Nelson Santos wrote:
>So, based on the above requirements, public frameworks, dynamic
>libraries and embedded frameworks are out. So, what are my other
>options? A static lib for each .h/.m combo?
A static library can contain more than one object file.
See 'man libtool'. Note the -static option.
You'd still have separate .h files for each component, but that's normal.
Just put them all in a single dir somewhere.
>Plus, I'd have to create a
>project dependency for each project to make sure I compile the latest
>code to have the most up-to-date library.
Well, now it sounds like you want the features of both a static lib and a
dynamic lib. You can't. You have to pick one, and accept the tradeoffs
that come with the particular form. Engineering is the art of making
tradeoffs.
>Ideally, I'd like it to be as easy as an #import <myheader.h>, but
>this won't import the implementation files. Do I have to locate and
>drag the .m files into the project and #import the header for each
>project that needs 'em?
If the .m's are compiled into a static library, then you just link against
that one library. If they're compiled as a framework or dylib, then again
you link against that one framework or dylib. In short, if your components
are compiled as a library, there aren't any .m's you'll be dragging into
any projects.
On the other hand, if you want to treat your components as a "source
library", then you can do that, too. Make it a cross-project reference to
the whole project and then you just have one reference to drag into an app
that uses it. Otherwise keep one set of source, and pick and choose which
components you'll use, but then you'll have to add each component
separately to every project you use it in.
There's no one answer because each possible answer has different tradeoffs.
You need to get a clear grasp of what each format brings with it, both
advantages and disadvantages, write them down in a list, then prioritize
the list. You've listed some requirements, but are they REALLY
requirements, i.e. hard and fast and unchangeable? In any case, you
haven't prioritized them, so if you had to eliminate one, which one would
it be?
Since it's YOUR library, and YOUR way of working, YOU are the only one who
can do this. Asking other people will just get THEIR opinion of how THEY
work within THEIR priortized requirements. Besides that, how you work may
change over time, and what's good now may be replaced by something you like
better later on.
There's no better way to do this than to try it yourself and see what works
for you. If one thing doesn't work for you, then you try the next thing on
your prioritized list. Experience is the best teacher, but only experience
can teach that.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden