The stripping issue is came up for me because I do have dead-code
stripping turned on so that the individual plugins aren't any larger
than they need to be. The main impetus for the static library was as
a repository for various code pieces that may or may not be used for
a particular plugin, but which rarely need to be rebuilt as compared
with the plugin itself.
What I did was to create a separate project file with a static
library target that included all of the .h, .mm and .cpp files that
go into the static library. That build creates the static library. I
make sure that the build works and that I end up with an appropriate
object file.
For my plugins, I'd create a project file with a single target. I
drag the static library into the project and assign it to the target,
then drag the static library's project into the file area for the
plugins project but -don't- assign it to the target. If you then
double-click on the target icon, under the General tab you can click
on the plus (+) button and select the static library target in its
project. That will create a dependency between the target you just
created and the static library project so that the static library
will be built (if necessary) before your target is built.
If you want to have one target per project, you can duplicate the
project file as a template; if you want all of your targets in a
single project file, you can likewise duplicate the target as a
template so that you start off with both the inter-project dependency
as well as the inclusion of the static library.
As for where to put the common header and static library, that's
really your choice. In my case, all of the plugins go together so I
made several per projects (one for each group of plugins) within a
single folder, then created a "common library" subfolder to hold the
hierarchy of files in the static library and other subfolders to hold
the per-plugin sources. I end up with a "../../CommonLibrary/
CommonLibrary.h" sort of path for the static library's header but
that hasn't been a problem since the path doesn't change.
steve
On Jul 6, 2009, at 11:30 AM, Alexander Bokovikov wrote:
Thank you for the reply,
It looks like your case is just what I'd like to have, though my
situation is simpler, as my shared code is the same for different
projects (though different projects may include other different
pieces). Therefore the problem of code stripping (which you
described) should not appear for me.
Nevertheless, I'd appreciate it highly, if you'll guide me through
the XCode project settings adjustment, as it sounds foggy for me,
how to make static library to rebuild itself when main project is
built. What particular settings should I add to the main project?
Also it's not clear, where to put that "common" header file? What
is the correct location for that? Am I correct in my understanding,
that placing this .h file into the right place I'll have the
ability to include my classes (stored in static library) by single
#import<mysubdir/myincfile.h> ? If yes, then it is just, what I'd
like to get! The same question is about static library itseklf --
where it should be located? Should I create my own directory system
or is it better to use some standard (system) directories for that?
If I must use my own directories, then where should I add a path to
them to avoid the necessarity to add this path to every new XCode
project manually?
Thank you.
----- Original Message ----- From: "Steve Christensen"
<puns...@mac.com>
To: "Alexander Bokovikov" <openwo...@uralweb.ru>
Cc: <cocoa-dev@lists.apple.com>
Sent: Monday, July 06, 2009 9:30 PM
Subject: Re: How to share Cocoa classes?
I build a number of plugins and ended up with a lot of shared code
so I ended up creating a project that builds a static library
with all those pieces, then make all my plugin targets dependent
on it so that it gets [re-]built first. I created a common
include file that includes all the headers for the code in the
static library and then include that header in all my plugins.
That keeps the included headers list in the various plugins neat,
plus makes it easy to add new stuff to the library without having
to update headers all over.
As for linking, so far I haven't had any problems. The only issue
I've ever run into is the case where I have a custom NSView class
that doesn't get directly referenced in the code because it's
being managed from the nib via bindings. In that case I've just
added a "if ([MyViewClass class] != NULL)..." to a window
controller's +initialize method to force that code not to be
stripped, since I do want any classes in the library that I'm not
using for a particular plugin to be stripped out.
steve
On Jul 6, 2009, at 1:23 AM, Alexander Bokovikov wrote:
Maybe it's a dummy question, but I can't find a way to share
some ObjC classes with several XCode projects. I've created a
set of Cocoa classes (.h and .m files) What I'd like to get is
the ability to write something like this:
#import <MyDir/MyClass.h>
I don't want to distribute these classes, as a framework, but I
would like just to link them directly into every executable,
which refers them. As I heard, a static library, having ObjC
classes inside, may cause some problems in linking. Therefore I
yet didn't try this way.
My question is: can I copy these shared files (.h + .m) into
some system directory to make them being visible for any Cocoa
project through the import directive, like above?
If no, then what is the correct way to go besides manual
inclusion of the same files into every XCode project?
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
