[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. http://www.ogre3d.org
    • 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