[OT] XCode integration and lib design


    Dec 11 2007 | 1:16 am
    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

    • Dec 11 2007 | 3:10 am
      > * 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
    • Dec 11 2007 | 9:16 am
      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.
    • Dec 11 2007 | 9:29 am
      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.
      >
    • Dec 11 2007 | 12:13 pm
      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
    • Dec 11 2007 | 7:23 pm
      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.
    • Dec 12 2007 | 1:05 am
      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
    • Dec 12 2007 | 1:10 am
      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
      >
      >
      >
      >
    • Dec 12 2007 | 6:13 pm
      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