[geos-devel] Interface changes

strk strk at keybit.net
Wed Jun 16 11:03:22 EDT 2004


On Wed, Jun 16, 2004 at 05:00:10PM +0200, strk wrote:
> On Wed, Jun 16, 2004 at 10:31:53AM -0400, Ferdinando Villa wrote:
> > On Wed, 2004-06-16 at 10:28, Ferdinando Villa wrote:
> > > Yes, or better, have these defined in geos_version.h and include it
> > > first thing in geom.h (btw - shouldn't it be geos.h, or maybe we should
> > > have a geos.h including geos_version.h and geom.h?). I usually prefer to
> > > have version numbers configured in configure.in and use the gcc command
> > > line to propagate them, but this has the disadvantage of needing a
> > > different strategy for Windows. Your defs and interface functions sound
> > > great to me.
> > 
> > ...on second thought, having it #defined in a header file will prevent
> > automake checking through a macro, as done in geos.m4, and require
> > tedious programming using geos-config (the configuration script won't
> > know the version, and I would strongly argue against duplicating the
> > info). So maybe there are arguments to keep the four defines as
> > variables in configure.in, although I don't know what's required to do
> > the same in Win.
> 
> The main GEOS application is Postgis.
> Postgis does not have an autoconf interface, so geos.m4
> won't be useful for it. It will *need* #defines to work
> correctly. 
> 
> As for geos.h / geom.h there is currently no single header
> defining all the operations available with geos.
> Postgis - for example - includes geom.h and util.h (another 
> *really* dangerous name).
> 
> Maybe GEOS should provide a 'public' geos.h containing all public
> and protected interfaces as well as version infos. This could
> hopefully be done automatically.

Oh... I forgot to mention... using geos.h would be yet another
"interface" change client applications should take care of,
and this time only geos-config could help finding out how.

--strk;

> 
> Finally, for the geos.m4 macro. I see no problem in writing
> version info in configure.in. The geos_version.h (or geos.h)
> would be substitution targets the same as geos-config.
> 
> --strk;
> 
> > 
> > 
> > > ferdinando
> > > 
> > > 
> > > > I think these would be useful to have:
> > > > 	#define GEOS_MAJOR_VERSION 1
> > > > 	#define GEOS_MINOR_VERSION 4
> > > > 	#define GEOS_PATCHLEVEL 0
> > > > 	#define GEOS_VERSION "1.4.0"
> > > > 	int geos::geos_major_version();
> > > > 	int geos::geos_minor_version();
> > > > 	int geos::geos_patchlevel();
> > > > 	string geos::geos_version();
> > > > 
> > > > Comments ?
> > > > 
> > > > BTW, to split version in major/minor/patchlevel configure.in should also
> > > > be modified..
> > > > 
> > > > > 
> > > > > One point about version numbers: the geos.m4 macro file that I added to
> > > > > the distribution (which defines GEOS_INIT(version) to be used in
> > > > > configure.in by any automake-based program that wants to check for geos)
> > > > > depends on having all three version numbers, and will not work correctly
> > > > > with two. So if we want that to keep working, we should have 1.4.0, not
> > > > > 1.4, or the m4 macro should be made smarter (probably a better idea).
> > > > 
> > > > probably a better idea...
> > > > 
> > > > --strk;
> > > > 
> > > > > 
> > > > > Ciao,
> > > > > ferdinando
> > > > > 
> > > > > On Wed, 2004-06-16 at 09:18, strk wrote:
> > > > > > I've updated GEOS interface to make all geometry constructors
> > > > > > copy given arguments (vector AND content).
> > > > > > 
> > > > > > As a side effect:
> > > > > > 
> > > > > >         o SegmentString constructor also copy given CoordinateList
> > > > > >           and deletes it at destruction time
> > > > > > 
> > > > > >         o SegmentString::getCoordinates() returns a copy of internal
> > > > > >           CoordinateList
> > > > > > 
> > > > > >         o new SegmentString::getCoordinatesRO() returns a pointer to
> > > > > >           the internal CoordinateList (no copy involved)
> > > > > > 
> > > > > >         o GeometryFactory::buildGeometry always returns a newly
> > > > > >           allocated geometry, so that the caller is free to delete
> > > > > >           arguments passed to it.
> > > > > > 
> > > > > >         o GeometryFactory geometry collection creators
> > > > > >           (createMulti*, createGeometryCollection) copy given
> > > > > >           vector AND content.
> > > > > > 
> > > > > > Reasoning about clients switched I've found that geos-config was 
> > > > > > broken in GEOS-1.0 (run with --version returned @@GEOS_VERSION@@
> > > > > > instead of actual version). I've fixed that, but I think a version
> > > > > > number (major,minor,patchlevel) should be put in some header for
> > > > > > ease of use. What do you think Frank ?
> > > > > > 
> > > > > > --strk;



More information about the geos-devel mailing list