[postgis-devel] Updates to GEOS & POSTGIS

[Paul Ramsey]

That's good. I didn't realize we had a GEOS version string floating  
around for the pre-processor to grab. What I meant was exactly what  
you did, there should be other examples wrapped inside the USE_GEOS  
define, for the "ain't got no GEOS" case.

P

On Jan 21, 2008, at 2:45 PM, Ben Jubb wrote:

> I wrapped the bodies of the new functions I added to lwgeom_geom_c.c  
> with an #if test for the right version of the GEOS lib, along with  
> an #else part that throws a 'not implemented' error.  This  
> particular source file is definitely dependent on the GEOS library.   
> If the older version of GEOS is used, the 'prepared' functions will  
> throw an error.  I don't think this will cause a link error.
>
> Im not sure what you are refering to as 'GEOS stubs'.
>
> b
>
> Paul Ramsey wrote:
>> 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
>>
>> _______________________________________________
>> 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