[CMake] Re: OpenSceneGraph and CMake

[Mike Jackson]

Eric,
  I am in the process of writing something similar in CMake for our
own project. I have like 5 or 6 subprojects that need to be built
first. The code layout is similar to OST_OT_OP layout. I have one
CMake file in the Main directory that includes "../{other projects}
and now with one invocation of ccmake ../{Main Project} i can have all
the variables set that point to all the includes, the built libs and
all that stuff. And it actually works to boot.

   I can even say make {sometarget} and it will only build that target
( and any dependancies it has).. I am reasonably impressed at this
point with CMake.

This might give you some ideas on how to create the CMake Files for OSG_OT_OP.

OSG_OT_OP
|--CMakeLists.txt (Includes the SubDirs OSG, OT, OP)
|--OSG
      |---CMakeLists.txt
|--OT
     |---CMakeLists.txt
|--OP
     |---CMakeLists.txt

Mike Jackson

On 8/21/06, E. Wing <ewmailing at gmail.com> wrote:
> There's actually not too much going on the OSG list so don't worry
> about it too much. Perhaps the surprise was the fact that QMake also
> supports Xcode generation. I'm having trouble finding specifics on it
> though.
>
>
> As far as CMake questions go, I actually have a couple maybe you guys
> can answer now.
>
> Currently OSG has two major dependencies on two separate projects,
> OpenThreads and Producer. Typically the OSG source distributions come
> packaged with both other projects (but this will not be true of CVS as
> they have their own repositories). Both OpenThreads and Producer are
> technically stand-alone products with their own separate build
> systems. However, as a convenience, it would be very nice to be able
> to construct a CMake build system that can let us build all 3 in one
> shot (in place) while at the same time have a CMake build system that
> can build them individually for when they are downloaded separately.
>
> The current layout of the combined source distribution looks something
> like this:
>
> OSG_OP_OT-1.1.1/
>     OpenThreads/
>         include/
>             OpenThreads/
>         src/
>             pthread_src/
>             win32_src/
>         lib/
>
>     Producer/
>         include/
>             Producer/
>         src/
>         lib/
>
>     OpenSceneGraph/
>         include/
>             osg/
>             osgUtil/
>             ...
>         src/
>             osg/
>             osgUtil/
>             ...
>             osgPlugins/
>         examples/
>             osgforest/
>             osgplanets/
>             ...
>         lib/
>
>
> The current Makefile system currently requires you to go into
> OpenThreads first and type make (because Producer also depends on
> OpenThreads). Then if you want to build Producer without 'installing'
> OpenThreads, you must set a bunch of special long winded environmental
> variables to the paths of the headers and built libs which the
> Producer Makefile is set to respond to. You repeat this step with
> Producer. And then finally, you go to OpenSceneGraph and do it one
> more time.
>
> (FYI, in Xcode, I use the cross-project dependencies feature so you
> can just hit build in the OpenSceneGraph Xcode project, and it
> automatically references/invokes the separate Xcode projects for
> OpenThreads and Producer. If CMake can be used to generate this
> behavior, I would be very happy.)
>
> Anyway, I would really like to improve this current Makefile scheme if
> possible so it is more a one step build without the user having to
> intervene with setting environment paths or 'installing'. At the same
> time, we still need to have separate/independent build systems for
> each project. I would like your suggestions on how to do this.
>
>
> Not to bias the overall question (as you may have a better solution),
> but one thing I have been playing with is how to reference the build
> libraries. One subtle problem I've come across is that I've been
> building the products in the same layout as how the source is laid
> out. In the case of OpenThreads, there are two different locations
> depending if you build pthreads or win32 threads, so it has made
> specifying this location much trickier than I would like. I'm
> wondering what the smarter thing to do here is.
>
> Thanks,
> Eric
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>


-- 
Mike Jackson
imikejackson _at_ gee-mail dot com