[postgis-devel] Re: sql files proliferation

Paul Ramsey pramsey at refractions.net
Sat Feb 28 10:42:32 PST 2004


OS/X cpp chokes for reasons I have yet to tease out. Probably not a 
good sign for platform portability...

cpp: Too many arguments


On Saturday, February 28, 2004, at 06:52 AM, strk wrote:

> I've added an experimental source sql file and a corresponding rule
> in the Makefile. CPP call is with -traditional-cpp flag, which
> is nicer with multiline strings and '--' comments.
>
> If you can give it a try we can test for compatibility.
>
> Run make postgis_new.sql (it's not built by default) to
> get postgis_new.sql generated from postgis.sql.in.
> The source file (postgis.sql.in) is not optimized to use
> cpp features, it just a copy of all the files previously
> used wrapped in #if USE_VERSION == <ver> blocks.
>
> Runnign a diff between postgis.sql and postgis_new.sql should
> give you just comments, blank lines and the postgis_version()
> function with double quotes ('') instead of slash escaped (/')
> quote inside the SQL function.
>
> --strk;
>
> strk wrote:
>> pramsey wrote:
>>> I wonder if we can use cpp and simple #ifdef stuff to do the
>>> preprocessing. Would be nice.
>>> P.
>>
>> I made some use of cpp with languages other then C.
>> The main problem is that cpp thinks #-lines are overlooked byt
>> the compilers. GNU cpp version accepts -P to omit linemarkers
>>
>>        -P  Inhibit generation of linemarkers in the output from
>>            the preprocessor.  This might be useful when running
>>            the preprocessor on something that is not C code, and
>>            will be sent to a program which might be confused by
>>            the linemarkers.
>>
>> ... but that could not be always the case.
>>
>> Can people try that (or similar) to solve the linemark problem ?
>>
>> --strk;
>>
>>> strk wrote:
>>>
>>>> The postgis*sql* files are becoming a major part
>>>> of the distribution (as number of files).
>>>> What about having a single sql for each postgres version ?
>>>> Or - better - use some preprocessing to keep in common
>>>> things that are common and spilt things that need to be
>>>> splitted ?
>>>>
>>>> I need to move geometry_column creation out of _common_
>>>> into each of version-specific files because for PG75 there
>>>> is no need of attrelid oid, varattnum int and stats histogram2d;
>>>> this already happended for schema support changes 
>>>> (addGeometryColumn,
>>>> dropGeoemtryColumn, fix_geometry_columns) and is getting boring.
>>>>
>>>> --strk;
>>>
>>>
>>> -- 
>>>        __
>>>       /
>>>       | Paul Ramsey
>>>       | Refractions Research
>>>       | Email: pramsey at refractions.net
>>>       | Phone: (250) 885-0632
>>>       \_
>>>
>>> _______________________________________________
>>> 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
>>
      Paul Ramsey
      Refractions Research
      Email: pramsey at refractions.net
      Phone: (250) 885-0632




More information about the postgis-devel mailing list