[OT] XCode integration and lib design
Dear list,
I'm developing a set of externals+shared library on Windows using Visual
Studio, and now I want to port the whole thing to Mac. My problem is, I've
never done anything big in XCode, and I'm not sure how to go about
organizing everything. All of the externals depend on the same shared
library. In VS I have all the different projects (externals) + the library
in one "solution", but I probably prefer to completely separate the library
from the externals.
I started off combining several externals into one xcode project. Creating
subfolders and build targets in the IDE for each object. So far it has
already been raising some questions and since its quite a lot of work I
thought I'd ask some advice first. Two issues with my current approach I can
think of:
* It seems like only one build target can be active at the time. This is a
problem if I want to rebuild all the externals at once (after updating the
shared library for example)
* Since everything is in one xcode project file, using a versioning system
might not be very practical (?)
Can someone please give some advise on how to organise a project like this?
Since its cross platform, I want to separate the code from the build /
project files. I guess its also better to make a separate project for the
framework/library? Is it recommended to learn xcode shell scripts?
On a similar note... For a while I've been searching for a book or online
resource about C/C++ library design "best practices". I'm always wondering
how to organize files, where to put includes, platform specific stuff,
globals, typedefs, macros, how to best use the library as includes for the
externals that depend on the library, how to hide part of the API /
interface, #pragma related things..... etc. So far I haven't found anything
useful, and wasted quite a lot of time with trial and error, learning bits
from other peoples code. If anyone can point me to a good resource I'd be
very grateful.
Cheers,
Thijs
> * It seems like only one build target can be active at the time. This is a
> problem if I want to rebuild all the externals at once (after updating the
> shared library for example)
I think you want a Aggregate Target new target-> special -> aggregate.
>
> * Since everything is in one xcode project file, using a versioning system
> might not be very practical (?)
>
I don't see why not.
> Can someone please give some advise on how to organise a project like this?
> Since its cross platform, I want to separate the code from the build /
> project files. I guess its also better to make a separate project for the
> framework/library? Is it recommended to learn xcode shell scripts?
>
> On a similar note... For a while I've been searching for a book or online
> resource about C/C++ library design "best practices". I'm always wondering
> how to organize files, where to put includes, platform specific stuff,
> globals, typedefs, macros, how to best use the library as includes for the
> externals that depend on the library, how to hide part of the API /
> interface, #pragma related things..... etc. So far I haven't found anything
> useful, and wasted quite a lot of time with trial and error, learning bits
> from other peoples code. If anyone can point me to a good resource I'd be
> very grateful.
In general, it's best to have well parameterized config file that has
things like project-wide defines for things like floating point
precision, extern or inline syntax etc. Take a look at the
well-designed open source projects like Open Dynamics Engine etc. to
get ideas for this. Then there is also typically a project wide
include file. In Jitter this would be jit.common.h. I think this
kind of stuff just comes from experience and using lots of libs to get
ideas.
wes
This doesn't really work properly in XCode, but you can give it a shot
-- XCode doesn't properly support subprojects, in my experience.
You're probably better off writing a shell script to batch-build.
jb
Am 11.12.2007 um 04:10 schrieb Wesley Smith:
> I think you want a Aggregate Target new target-> special ->
> aggregate.
Subprojects are different than aggregate targets, aren't they? I've
never had a problem with aggregates, though setting up multi-project
dependencies seems a little more involved.
r.
On 11-Dec-07, at 10:16 PM, Jeremy Bernstein wrote:
> This doesn't really work properly in XCode, but you can give it a
> shot -- XCode doesn't properly support subprojects, in my
> experience. You're probably better off writing a shell script to
> batch-build.
>
> jb
>
> Am 11.12.2007 um 04:10 schrieb Wesley Smith:
>
>> I think you want a Aggregate Target new target-> special ->
>> aggregate.
>
Thanks guys!
I'll try both aggregate targets and see if I can lean how to do build
scripts as well, to decide what i like best. Thanks to Wes for mentioning
ODE. I will take a close look at its structure and try to learn from it.
Best,
Thijs
yeah, sub-projects are a bit different then aggregates, but i think that is as close as it comes.
for instance a visual studio solution with multiple projects, which have dependencies on each other (i think what you mean by sub-projects), can be replicated with xcode with one project and several targets, or an aggregate target.
each target has its own build properties and source that it compiles, and the ordering can be controlled by the aggregate target.
another good opensource project to look at, which gives a good example to compare and contrast visual studio and xcode is ogre3d.
http://www.ogre3d.org
On Dec 11, 2007 7:23 PM, Robert Ramirez wrote:
>
> yeah, sub-projects are a bit different then aggregates, but i think that
> is as close as it comes.
> for instance a visual studio solution with multiple projects, which have
> dependencies on each other (i think what you mean by sub-projects), can be
> replicated with xcode with one project and several targets, or an aggregate
> target.
> each target has its own build properties and source that it compiles, and
> the ordering can be controlled by the aggregate target.
>
> another good opensource project to look at, which gives a good example to
> compare and contrast visual studio and xcode is ogre3d.
> http://www.ogre3d.org
>
>
Thanks Robert,
So far I like the way aggregates work.
I have one last question though. I'd like to start the Max RT with different
test patches for debugging. Instead of launching the app from XCode and then
manually opening a debug patch, I want it to open the patch on load
automatically.
In the terminal I can successfully do this using:
open -a "MaxMSP Runtime.app" /Users/me/Desktop/mydebugpatch
I can't seem to get XCode to do the same. When I put
/Users/me/Desktop/mydebugpatch in the executable arguments section, nothing
happens when Max is launched. In the docs they state that the arguments are
similar to command line arguments, so I don't see why this wouldn't work.
Any clues?
This is the last XCode question I promise, I'll join the mailing list for
the next one ;-)
Thijs
I tried my hand at this a while back with no luck. Just put the patch
in your xcode project and double click it after launching the runtime.
wes
On Dec 11, 2007 5:05 PM, Thijs Koerselman wrote:
> On Dec 11, 2007 7:23 PM, Robert Ramirez wrote:
>
> >
> > yeah, sub-projects are a bit different then aggregates, but i think that
> is as close as it comes.
> > for instance a visual studio solution with multiple projects, which have
> dependencies on each other (i think what you mean by sub-projects), can be
> replicated with xcode with one project and several targets, or an aggregate
> target.
> > each target has its own build properties and source that it compiles, and
> the ordering can be controlled by the aggregate target.
> >
> > another good opensource project to look at, which gives a good example to
> compare and contrast visual studio and xcode is ogre3d.
> > http://www.ogre3d.org
> >
> >
> >
> >
> >
>
>
> Thanks Robert,
>
> So far I like the way aggregates work.
>
> I have one last question though. I'd like to start the Max RT with
> different test patches for debugging. Instead of launching the app from
> XCode and then manually opening a debug patch, I want it to open the patch
> on load automatically.
>
> In the terminal I can successfully do this using:
> open -a "MaxMSP Runtime.app" /Users/me/Desktop/mydebugpatch
>
> I can't seem to get XCode to do the same. When I put
> /Users/me/Desktop/mydebugpatch in the executable arguments section, nothing
> happens when Max is launched. In the docs they state that the arguments are
> similar to command line arguments, so I don't see why this wouldn't work.
>
> Any clues?
>
> This is the last XCode question I promise, I'll join the mailing list for
> the next one ;-)
>
> Thijs
>
>
>
>
On Dec 12, 2007 1:10 AM, Wesley Smith wrote:
> I tried my hand at this a while back with no luck. Just put the patch
> in your xcode project and double click it after launching the runtime.
>
>
That's too bad. It would have been nice to automate the process all the way.
O well... thanks for letting me know.
Thijs