Compile-time unit tests

Boost Build V2 includes testing module that provides nice features for running unit tests. A unit test run means a test builds and can be executed performing checks in run-time, however, a unit test can be also based on compilation or even linking result. Yet more surprisingly, sometimes a test is expected to not to compile and such failure is considered as success. It performs compile-time checking in design by contract.

In Generic Geometry Library, some tests use that feature of testing compilation result. For example, this way it’s possible to test the concepts in practice and to ensure that various constructs are not accepted by the library as expected by design.

For example, custom_linestring.cpp source file can be used to perform compile-time and run-time testing. If TEST_FAIL_APPEND is defined, unacceptable constructs are compiled and the compilation is expected to fail. If compiled without TEST_FAIL_APPEND defined, only acceptable code is enabled and regular run-time test performed.

Configuration of such thing is very easy with Boost Build V2. Here is Jamfile.v2 that performs the test for geometries in Generic Geometry Library using compile-fail rule:

test-suite ggl-geometries
    :
    [ compile-fail custom_linestring.cpp
        : # requirements
        <define>TEST_FAIL_APPEND
        : # target name
        custom_linestring_test_fail_append
    ]
    [ run custom_linestring.cpp ]

There are among others also rules like compile, link-fail and link.

The unit tests execution is simple:

mloskot@dog:~/dev/ggl/_svn/trunk/libs/ggl/test/geometries$ bjam | grep passed
**passed** bin/custom_linestring_test_fail_append.test/gcc-4.4.1/debug/custom_linestring_test_fail_append.test
**passed** bin/custom_linestring.test/gcc-4.4.1/debug/custom_linestring.test

Building PostGIS using Visual C++

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.6official 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

WKT Raster crash course #1

Recently, a good friend of mine Sandro has started spreading the story of WKT Raster project. Here, I’d like to join him and post a bunch of technical notes about how to start using tandem of PostGIS and WKT Raster. This is the first post that hopefully will start a series discussing various aspects of use and development of WKT Raster extension.

What

From the overview of WKT Raster project:

WKT Raster is an ongoing project aiming at developing raster support in PostGIS. (…) WKT Raster’s goal is to implement the RASTER type as much as possible like the GEOMETRY type is implemented in PostGIS and to offer a single set of overlay SQL functions (like ST_Intersects) operating seamlessly on vector and raster coverages.

The idea of WKT Raster extension was presented (PDF 1.1 MB) in December 2008 by Pierre Racine from University Laval. Pierre’s presentation made foundation of the WKT Raster Specification.

Hacker #1: Why WKTRaster? sounds a bit silly :D
Hacker #2: Apparently the initial thoughts on it were expressed using a textual representation for the rasters and the thinking was that this would be core to the effort, though it has proven not so important. I also find the name unhelpful.

Actually, this is not as trivial problem as it may seem. I am not sure myself that the name is WKT Raster or WKTRaster, nor I’m confident if the name is fixed and will be valid in future.

Update 2009-03-08 14:05: See Pierre’s comment below.

Where

At the moment, WKT Raster project does not have a single home, but different parts of it live in different places:

Who

Currently, there is a small team of people who contribute their time, skills and money to move the project forward. Here is a summary of contributors everyone can collect from the scattered homepage(s) of WKT Raster:

  • Pierre Racine – originator and author of the WKT Raster idea and specification and implementation developer.
  • Sandro Santilli – well-known member of the PostGIS core team who is the architect of RASTER type definition, canonical and Well-Known-Binary format of stored raster, developer of input/output operations, and more.

There are also prime financial contributors who established development of the WKT Raster project: Steve Cumming, Martin Daly (from Cadcorp, where I work as member of core development team) and Tyler Erickson.

Recently, I’ve also joined the WKT Raster team and being led by Martin Daly I’m focused on programming new features and core testing.

News

Today and during next 3 days, a few people interested in the PostGIS / WKT Raster project are meeting together for the Toronto Code Sprint 2009. I’m also present there, though in spirit by joining the event on #tosprint IRC channel. I have a hope that during this meeting, we will discuss and agree about a couple of outstanding issues:

  • meta data tables: Do we need them? How to define schema of meta data?
  • review of specification of RT functions
  • improvements in the solution architecture and design to handle common raster use cases, for both categories, visualizations and analysis
  • how to answer needs of pyramids/overviews
  • does the project need an infrastructure, a new home?
  • and last but not least, how to achieve sustainability and rise more funds.

By the way, isn’t it good time to create WKT Raster article on Wikipedia? Writers are welcome!