I almost finished crafting CMake configuration for libLAS. It is available from the repository in the main branch. It is possible to build libLAS library and command line utilities configured with most of supported dependencies: GDAL, GeoTIFF and SpatialIndex. Configuration of Oracle and Boost dependencies is not ready yet. It is also possible to install libLAS run-time and compile-time components. Cool!
Detailed story with extensive example of how to use CMake to build libLAS is available here in Trac. I have successfully tested it on Linux (Ubuntu 9.04). I’m going to test & update it on Windows with Visual Studio – generally it (compilation) works but dependencies selection and installation commands haven’t been tested.
I’m very pleased I can officially announce CMake configuration availability. I truly hope to make my life and users life easier – maintenance of Visual Studio projects is just ridiculously tedious and time consuming.
Preparing CMake configuration was a very useful experience and I’m going to use it to improve other projects this way (like SOCI, Generic Geometry Library). I would be happy to see interest in preparing CMake configuration for GDAL/OGR too…any brave hearts out there?
Why CMake? Because CMake is the best build system ever delivered to Open Source community. Full stop.
Projects of all types, ages and sizes evaluated CMake, came to the same conclusion and eventually migrated to use CMake. To give examples of large or established projects, here we go:
- Boost C++ Libraries used to be firmly wedded to bjam (still main builder), they have learned about CMake features and currently
migration to CMakedevelopment of CMake-based configuration is well in progress and their community is being taught about CMake. - KDE switched to CMake in the middle of 2006
- Quantum GIS thanks to Martin Dobias started migrating to CMake shortly after KDE.
By the way, I’ve started collecting custom reusable CMake modules – available from my workshop repository. They can be used to complete, large collection anyway, of standard CMake modules.
Hi Mateusz,
I’m actually interested by a CMake configuration for GDAL. Few weeks ago, I gave it a try and I have a working CMakeLists.txt which compile gdal and one of its application.
So far (as a demonstration), there are only two formats compiled: one using the internal version provided with gdal (png) and one using the system version (tiff).
It will be great if we can cooperate on this, let me know!
Emmanuel
Hi Emmanuel,
Great! Yes, I think I would be interested in joining your effort. Do you host this configuration in some public repository (SVN?). If not, I can host it in my personal Git repository.
I’ll push it to a mercurial google code repository tomorrow, is that ok with you?
Sure, wherever.
It’s concerning how many folks claim that Boost is switching to CMake, while this is not the case, at least yet. Had I expected this effect, I surely would object to addition of any trace of cmake to either trunk or release branches.
Vladimir,
Thank you for clarification. I admit it was not very clear to me. I updated my post to reflect that the CMake adoption is not migration.
I’ m also interested in tiff and gdal CMake build….
If you have something working, I would really be glad to know….
I’ve helped also the cmakeports http://code.google.com/p/cmakeports/
Regarding Boost …. maybe is unofficial… but seem someone is working on
http://sodium.resophonic.com/boost-cmake/current-docs/
Luigi,
I prepared CMake configuration for libgeotiff – see ticket #17. libtiff should be piece of cake to do :-)
I also try to help Emmanuel with CMake for GDAL, however recently I’ve been busy with other things. Basic GDAL features are available for CMake, as far as I remember.
Regarding Boost, yes it’s a known project lead by Troy.