Copying these couple of mails to a doc inside the sources or to a wiki page will help users I guess.
I use cmake everyday in kde and I they just make use build directory not an option. It requires the build dir. Things become much cleaner

On Wed, Apr 23, 2008 at 2:46 PM, Geoffrey Biggs <> wrote:
One other thing I forgot to mention: thanks to CMake we have full
support for different build configurations now (well, in the build
system, anyway). The current configuration is set in the
CMAKE_BUILD_TYPE variable (run ccmake to see it). The four provided by
default are Debug, Release, MinSizeRel and RelWithDebInfo. If the flag
is empty (currently the default), no particular flags are added to the


Geoffrey Biggs wrote:
> The merge is all done. The trunk now uses CMake for its build system.
> For those who haven't used CMake before, the process of configuring and
> building is slightly different to autotools. Here's what I do:
> 1. Create a subdirectory of the source directory called "build"
> 2. Change to this directory and run "cmake ../"
> 3. If I want to change any options, such as paths to libraries, install
> prefix (that's CMAKE_INSTALL_PREFIX) or which drivers are compiled, I
> run "ccmake ../" and use the GUI to change them (ccmake does not require
> that cmake be run first).
> 4. Once the configuration meets my needs, run "make" in the "build/"
> directory.
> 5. Run "make install" to install to my chosen prefix.
> 6. "make clean" works as normal in "build/" to remove the compiled
> object files while leaving the generated make files alone.
> 7. "make realclean" or whatever is as simple as emptying "build/".
> 8. "make uninstall" should work as normal. If it doesn't, "xargs rm <
> install_manifest.txt" will work perfectly.
> I strongly recommend doing a clean checkout. While make distclean
> *should* clear out everything, the less errors caused by files leftover
> from an autotools build as people get used to this new build system, the
> better. It is probably a good idea to completely uninstall your old copy
> of player installed from trunk, too.
> I also recommend doing an out-of-source build (the process described
> above) rather than an in-source build, purely from an
> ease-of-maintenance point of view.
> Clients should compile as normal against the libraries produced by this
> build. A CMake module to make compiling clients and plugins easier is in
> progress.
> If you want to help finish off the build system, see the file
> "CMake_Todo.txt" in the root directory. There's also a CMake_README.txt
> in there, too. There drivers in the list below may not configure/compile
> as I can't compile them here. If you have any of them enabled, problems
> are possible. Feel free to report the problems here if you don't want to
> try fixing the build scripts yourself.
> -- The following drivers will not be built:
> -- amtecm5 - Could not find header Device.h
> -- artoolkitplus - Could not find package artoolkitplus
> -- shapetracker - Could not find package opencv
> -- simpleshape - Could not find package opencv
> -- upcbarcode - Could not find package opencv
> -- camera1394 - API version checks are a mess - will do later
> -- imageseq - Could not find package opencv
> -- yarpimage - Could not find header yarp/os/all.h
> -- statgrab - Could not find package libstatgrab
> -- eedhcontroller - Disabled - probably doesn't build
> -- lifomcom - Disabled by default
> -- chatterbox - Experimental
> -- garcia - Could not find package libgarcia
> -- nomad - Disabled by default
> -- phidgetifk - Could not find header /phidget21.h
> -- reb - Disabled by default
> -- segwayrmp - Disabled by default
> -- robotino - Could not find header robotinocom.h
> -- sr3000 - Could not find header libusbSR.h
> -- isense - Could not find header isense/isense.h
> -- phidgetRFID - Could not find header /phidget21.h
> -- service_adv_mdns - Disabled by default
> -- sphinx2 - Disabled by default
> -- postgis - Could not find header geos_c.h
> -- vec2map - Could not find header geos_c.h
> -- rcore_xbridge - Could not find header libparticle.h
> And for my next trick: a Windows port of the bits of XDR we need,
> followed by a Windows port of Player...
> Geoff
> Toby Collett wrote:
>> A make distclean before an svn update should also do a reasonable job of
>> keeping things clean...
>> Toby
>> On 19/04/2008, *Geoffrey Biggs* <
>> <>> wrote:
>>     Thanks to a free Friday afternoon, I've just about merged all the
>>     relevant changes from trunk into the cmake branch. Once this is
>>     complete, it should be relatively trivial to merge the branch into
>>     trunk. The change will probably still be a bit disruptive, though, so
>>     I'd like to set Wednesday (Japan time) for it.
>>     If you have any outstanding changes please commit them before that. Keep
>>     in mind that the cleanest way to transition to across this merge will be
>>     to check out a fresh copy of the source. Subversion will take care off
>>     all the deleted versioned autotools files, but there will be a lot of
>>     generated cruft in your source directory that SVN won't get rid of.
>>     Geoff
>>     Geoffrey Biggs wrote:
>>      > Toby Collett wrote:
>>      >> P.P.S Geoff, do you want to put a plan/timeline for integrating
>>     cmake
>>      >> into trunk to the list?
>>      >
>>      > Not really, because then I'll have to stick to it, but since I
>>     should...
>>      > I probably won't have time until next week at this stage.
>>      >
>>      > Geoff
> -------------------------------------------------------------------------
> This email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> _______________________________________________
> Playerstage-developers mailing list

This email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.;198757673;13503038;p?
Playerstage-developers mailing list

Jordi Polo Carres
NLP laboratory - NAIST