Hi List,
the ./configure script supporting the next 4.2.0
will introduce the following changes:
--enable-libxml2=yes
the default setting for this option will be inverted;
enabling full libxml2 support will now always be the
standard configuration option assumed by default.
You could still continue to disable libxml2, but now
such action will require to set an explicit directive
--disable-libxml2
GEOS configuration options
==========================
GEOS v.3.4.2 is now the current stable version, and is
widely supported by many popular mainstream distributions;
so we can now safely assume that at least v.3.3.x should
be a reasonable "minimal version" required by SpatiaLite.
Accordingly to all this, it looks now rather extravagant
to still continue to mark as "GEOS_ADVANCED" features
supported by the minimal version, and as "GEOS_TRUNK"
features supported by the current stable version.
- now the basic assumption is that a decently recent version
of libgeos is always expected to be found: >= 3.3.x
- versions <= 3.2.x will not be any longer supported
- SQL functions such as ST_SharedPaths(), ST_ClosestPoint()
and ST_UnaryUnion() will now be considered to be integral
part of the plain GEOS main-core.
- SQL functions such as ST_DelaunayTriangulation(),
ST_VoronojDiagram() and ST_ConcaveHull() (absolutely
requiring GEOS 3.4.x support) will now be considered
to be part of the extended GEOS-Advances support.
- GEOS-Trunk will simply remain as a place-holder (may
by useful in future times), but in 4.2.0 it will be
an absolutely empty container.
GEOS configuration options
supported by spatialite 4.2.0
-----------------------------
--enable-geos=yes
default setting; >= v.3.3.x it the minimal requirement
--enable-geosadvanced=yes
default setting and necessarily requiring v.3.4.x;
just in case, when building on some platform simply
supporting v.3.3.x you'll be required to explicitly
set --disable-geosavanced
Please note well:
-----------------
enabling LWGEOM support will still require to explicitly
set a "--enable-lwgeom=yes" directive.
this is not due to technical reasons (PostGIS 2.0 is now
reasonably available on many mainstream distributions);
it simply is because by enabling LWGEOM you'll implicitly
accept that the whole SpatiaLite will become subject to
the "viral" GPL license.
So explicitly requiring to express some kind of "informed
consent" seems to be the most appropriate solution in
this case.
Anyway packagers and maintainers building libspatialite
on FLOSS platforms (i.e. Linux and alike) are always
invited to enable LWGEOM: and consequently the suggested
standard build configuration on any Linux is now:
./configure --enable-lwgeom=yes
bye Sandro