[geos-devel] Petition for a 2.2.2 release

[strk at refractions.net]

On Wed, Mar 29, 2006 at 12:21:24PM -0700, Charlie Savage wrote:
> Hi Strk,
> 
> Thanks for the patience.
> 
> Took a look at this last night.  The problems with the python make file 
> appear automake related.  IE., the generated build file is wrong.  It 
> includes @....@ markers that are not replaced by automake. No solution 
> yet, not sure what is going wrong.

I woudn't put too much effort in this, if nobody comes out
with a working solution we can revert to 2.2.2 behaviour
of just including sources in distribution w/out attempting
to automatically build them.

> Second, the change in the header files has broken SWIG.  SWIG doesn't 
> follow #includes, thus the bindings have to be updated to include the 
> correct #includes.  I am thinking of just adding in the ones defined in 
> geom.h and the io headers.  Does that sound right?

As far as SWIG uses it's own bindings the changes breaking it
are: namespaces addition and some classes rename. Hopefully
none of the omonimous classes in different namespaces needs
to be directly accessed by SWIG.
Headers included by geom.h and io.h might still be too wide
for my taste.
Try to only use headers named after classes.
As a sit-on-the-pants guess you'd need:
	Geometry.h
	GeometryFactory.h
	PrecisionModel.h
	CoordinateSequenceFactory.h
	Coordinate.h
	CoordinateSequence.h
	WKB{Reader,Writer}.h
	WKT{Reader,Writer}.h
	GEOSException.h 
	(actually derived from std::exception, so possibly
	 not even needed)

If you need access to Geometry derivates please use the
specific headers:
	Point.h
	LineString.h
	LinearRing.h
	Polygon.h
	MultiPoint.h
	MultiLineString.h
	MultiPolygon.h
	GeometryCollection.h

But the fewer, the better.
	

> To answer your question below, SWIG exposes the GEOS version, the 
> geometry classes, and the IO classes.  It also exposes a couple of other 
> header files that ended up being needed via includes from the top header 
> file.

With the new layout all "specific" headers use Forward Declarations
when possible, so the cascade effect should be much less intrusive.
A problem is that inlining makes this effect wider.
Inlining will be the default. Users will be able to disable
inlining. Wheter library was compiled with or w/out inlining
can be obtained by running geos-config --cflags. Inlined
builds will result in -DGEOS_INLINE being part of the flags.

> If you have suggestions on what should be exposed let me know.  It a 
> matter of pointing SWIG at the header files you want to be wrapped.

I hope the above answers your question.

--strk;

> 
> Charlie
> 
> 
> strk at refractions.net wrote:
> >On Mon, Mar 27, 2006 at 02:08:03PM -0700, Charlie Savage wrote:
> >  
> >>Actually, the bindings work on both 2.2.2 and 3.0.  The main difference 
> >>is the renaming of a couple of classes, other than that the bindings 
> >>just mirror whatever the C++ api is.
> >>
> >>I'm fine either way on this, just thought it be nice to get out there 
> >>for people to use.
> >>    
> >
> >That's ok for me, it will delay release 2.2.2 by the time
> >needed to touch build scripts. If you provide them
> >looking at the python ones I'll wait.
> >
> >  
> >>Strk - any timeline on a 3.0 release?
> >>    
> >
> >Not yet. I'd like to receive some feedback
> >about reduction of installed C++ headers.
> >Beside, I didn't look at SWIG binding, how many
> >classes are actually exposed ? Maybe C++ exposure
> >could follow SWIG one.
> >
> >  
> >>And sorry, haven't looked at head yet...but will.
> >>    
> >
> >That'll also help releasing sooner.
> >
> >--strk;
> >_______________________________________________
> >geos-devel mailing list
> >geos-devel at geos.refractions.net
> >http://geos.refractions.net/mailman/listinfo/geos-devel
> >
> >
> >  



> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel


-- 

 /"\    ASCII Ribbon Campaign
 \ /    Respect for low technology.
  X     Keep e-mail messages readable by any computer system.
 / \    Keep it ASCII.