[postgis-devel] Updates to GEOS & POSTGIS

[Paul Ramsey]

I'm not sure that will work, since the symbols for the new functions  
will be missing in the older versions... might we not end up with a  
link-time error?  The thing about the GEOS stubs is that they are  
wrapped in a USE_GEOS define that removes the library dependency.

P

On Jan 21, 2008, at 1:24 PM, Ben Jubb wrote:

> Ill implement your first suggestion, and stub the C functions for  
> the prepared stuff, moving the version detection to the  
> lwgeom_geos_c.c.  Seems friendliest to the long suffering VS users.
>
> b
>
> Paul Ramsey wrote:
>> Historically, we've left sql.in along and put in stubbed functions  
>> in the .c files, in the case of with-GEOS versus without-GEOS.  We  
>> could go whole hog and add GEOS version detection to ./configure.   
>> Might make things even worse for VCC workers.
>>
>> As of now, having trolled the code base, there is a geos_version.sh  
>> script which can write the version into a #define for use  
>> elsewhere.  The only running code that works with version is the  
>> run-time version print-out in postgis_geos_version().
>>
>> The most elegant thing would be to put it into ./configure, IMO,  
>> but I'm not sure that's the most *useful* thing.
>>
>> P
>>
>> On Jan 21, 2008, at 11:45 AM, Ben Jubb wrote:
>>
>>> My changes won't build against the GEOS 3.0.0 branch.  use the  
>>> trunk instead.
>>>
>>> I'm open to suggestions as to how to get the GEOS version  
>>> information into lwpostgis.sql.in.
>>>
>>> cheers
>>> b
>>>
>>> Mark Cave-Ayland wrote:
>>>>
>>>> On Fri, 2008-01-18 at 09:26 -0800, Ben Jubb wrote:
>>>>
>>>>
>>>>> Mark,
>>>>> thanks for the comments,
>>>>>
>>>>> - I'll change the comment style..
>>>>>
>>>>> - added the initGEOS() calls, oops..
>>>>>
>>>>> - the size calculation: ill try your suggestion for getting
>>>>> arg1_length.
>>>>>
>>>>
>>>> Hi Ben,
>>>>
>>>> I've just done a checkout of latest SVN, and unfortunately it seems
>>>> broken against the GEOS 3.0.0 branch :(
>>>>
>>>> I managed to get around the compilation failures by removing the  
>>>> line
>>>> "#define PREPARED_GEOM 0", but regression tests fail because
>>>> lwpostgis.sql.in still references these functions, and hence it  
>>>> fails to
>>>> load into PostgreSQL.
>>>>
>>>> So in order to support both newer and older versions of GEOS, there
>>>> needs to be some GEOS versioning directives around the new code  
>>>> in both
>>>> lwpostgis.sql.in and lwgeom_geos_c.c (rather than having to alter  
>>>> both
>>>> of these by hand).
>>>>
>>>>
>>>> ATB,
>>>>
>>>> Mark.
>>>>
>>>>
>>> <benjubb.vcf>_______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> <benjubb.vcf>_______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel