mark.cave-ayland at siriusit.co.uk
Wed Dec 17 07:19:02 PST 2008
Paul Ramsey wrote:
>> "100% liblwgeom related"? Why wouldn't the same harness be useful to test
>> methods in the loader, lwgeom, or any other c method for that matter?
> Not really. lwgeom starts to pull in dependencies on pgsql, so testing
> without a backend becomes a non-starter. That's the beauty of Mark's
> separate liblwgeom. Which is also, to my mind, a reason to migrate a
> much of pure geometry code (area, length, lrs) into liblwgeom, where
> it can be tested more directly.
Indeed. I think this will be one of the strengths of the new liblwgeom.
I'd much prefer to have a "make unit" or similar stress the entire
library much in the same way that Regina's torture script does.
One of my TODOs for 1.4 was to totally redo the regression tests, and so
I wouldn't complain at all if they were made into a set of carefully
designed cunit tests, with very minimal PostgreSQL testing. The main
reason for this is that the regression test script under Win32 is *slow*
- I'm talking under a minute to run the whole set on Linux against
around 10mins on Win32. So anything to speed this process up will make
things so much easier for me.
Paul will also vouch that finding memory leaks outside of PostgreSQL is
also considerably easier ;)
> liblwgeom/cunit it is
Cool. If this stuff really takes off, I could almost see liblwgeom
spinning into a standalone project. PostGIS simply becomes a set of
light-weight wrappers around liblwgeom, which could then also be used by
MySQL, Ingres, SpatiaLite... :P
Sirius Corporation - The Open Source Experts
T: +44 870 608 0063
More information about the postgis-devel