Tag Archives: cmake

Testing libLAS with CMake

Posted on by
Reply

libLAS - ASPRS LiDAR data translation toolset As a part of CMake configuration for libLAS, I’ve enabled support CTest. It is CMake test driver program that can be used to run automated tests and perform continuous integration. I also registered libLAS at CDash testing server.

CDash aggregates, analyzes and displays the results of software testing processes submitted from clients located around the world

Check libLAS dedicated quality dashboard – registration is required it is public project and available for anonymous visitors to browse the dashboard (thanks to Julien from Kitware for quick fix).

Anyone who is would like to build libLAS using CMake and run tests can find details on the CMake article on the Wiki. I would also encourage interested users to issue make Continuous to submit test results to the dashboard.

Feedback kindly wanted!

Building GeoTIFF with CMake

Posted on by
Reply

I’ve just submitted ticket to GeoTIFF Trac system with patch providing CMake build configuration for GeoTIFF library and utility programs.

#17 – CMake build configuration for GeoTIFF

It also includes FindGeoTIFF module for CMake users that need to determine availability of libgeotiff in their projects. Tests and improvements are welcome.

libLAS 1.2.1 Released

Posted on by
Reply

libLAS - ASPRS LiDAR data translation toolset Howard just posted announcement about patch of libLAS 1.2.1 release.

Detailed list of fixes includes:

  • #120 – support ‘comma’ as a separator in las2txt
  • #121 – las2txt and txt2las don’t work with the Point Source ID
  • #122 – las2las does not eliminate requested classifications
  • #124 – some files have pad bytes when they shouldn’t
  • #127 – Scan flags is order sensitive
  • #129 – Version.rc doesn’t make the release
  • #132 – Require libgeotiff when GDAL is requested
  • #133 – FreeBSD endian.hpp
  • #134 – GDAL transform translates the points incorrectly when there is a scale or translation on the points
  • #136 – Problem overwritting Reader’s dataoffset due to VLR
  • #139 – txt2las is not setting the point source id correctly for values > 255
  • #140 – liblas 1.2 linking problems due to –with-hide-internals gdal option
  • #141 – lasinfo in not reporting info about point source id
  • #143 – libLAS 1.2 requires GDAL 1.7 (unreleased)
  • #144 – Apps should take in filenames without -i argument
  • #145 – Memory leak from LASWriter / lasspatialreference assignment operator=
  • #148 – No prototype in core.py for LASPoint_Destroy

On behalf of the libLAS team, thanks to all who provided bug reports and patches!

Before delivering next major release of libLAS, there is one big issue that must be fixed. It is problem with large files under Windows 32-bit operating system – ticket #147. Volunteers are welcome to take care of it :-)

I would also like to see completed build configuration based on CMake – ticket #52. It is already usable on Unix (GCC) and Windows (Visual C++), so testers are welcome to give it a try and give us feedback.

Building libLAS with CMake

Posted on by
8

libLAS - ASPRS LiDAR data translation toolset 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:

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.

QGIS tracks on BoostCon’09

Posted on by
Reply

In one of presentations from this year’s edition of BoostCon, I found a small track of Quantum GIS project. This is Bill Hoffman‘s presentation titled A CMake-Based Software Process for Development and Integration Testing (PDF) and the track is citation taken from Martin Dobias’ blog post Having fun with CMake:

I was quite surprised with the speed of building Quantum GIS codebase in comparison to Autotools.

All presentations from the BoostCon’09 are available to download including Barend‘s slides and article with about Generic Geometry Library. There are much more interesting materials from the conference available and as another one somehow related to geospatial works, I’d like to point Graphics Programming Workshop about programming with Adobe’s Graphics Interface Library which is a part of Boost C++ Libraries (>= 1.35.0). There are both, slides and source codes, available to download.

Building PostGIS using Visual C++

Posted on by
8

I don’t like MinGW. I’ve been dreaming about building PostGIS using Visual C++ – the native development toolset for Windows platform – without being forced to install Unix-like environment inside Windows. Finally, I’ve got motivated enough and decided to make my dreams reality, so here is the story.

First, I collected all run-time dependencies required by PostGIS. I intentionally used the word run-time to indicate I’m not going to install MinGW neither Cygwin or any other GCC-for-Windows package. GNU make is also not required.

I use PostGIS source code from trunk in the Subversion repository.

Dependencies

There are only 3 software packages required:

  1. PostgreSQL 8.3.6 – official Win32 binaries and source code
  2. GEOS – build from sources, it’s safe to grab SVN trunk
  3. PROJ.4 – also build from sources and also from SVN trunk

I installed the PostgreSQL 8.3.6 without PostGIS extensions, as I’m going to provide my own :-), using default location c:\Program Files\PostgreSQL\8.3. The source code of PostgreSQL 8.3.6 went to d:\dev\postgresql\postgresql-8.3.6.

Short note on directories layout using for projects downloaded directly from repositories. Root path of source tree of each project have the same layout: D:\dev\PROJECT\_svn\trunk. For Visual Studio projects, these paths are defined as macros in postgis.vsprops (Visual C++ Property Sheet), so it should be easy to redefine them without any need to hack other project settings like Additional Include Directories and others.

Continue reading →