,/configure changes in 4.2.0

45 views
Skip to first unread message

sandro furieri

unread,
May 16, 2014, 12:07:57 PM5/16/14
to spatiali...@googlegroups.com
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
Reply all
Reply to author
Forward
0 new messages