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/"
> 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
> 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...
> Toby Collett wrote:
>> A make distclean before an svn update should also do a reasonable job of
>> keeping things clean...
>> On 19/04/2008, *Geoffrey Biggs* <firstname.lastname@example.org
>> 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.
>> Geoffrey Biggs wrote:
>> > Toby Collett wrote:
>> >> P.P.S Geoff, do you want to put a plan/timeline for integrating
>> >> into trunk to the list?
>> > Not really, because then I'll have to stick to it, but since I
>> > I probably won't have time until next week at this stage.
>> > Geoff
> This SF.net 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 SF.net 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