[postgis-devel] Re: sql files proliferation

[strk]

pramsey wrote:
> OS/X cpp chokes for reasons I have yet to tease out. Probably not a 
> good sign for platform portability...
> 
> cpp: Too many arguments

We could either find the right way to call CPP (autoconf?)
or maybe opt for a perl script, since this is already required,
to perform basic cpp (traditional) work.

--strk;

> 
> 
> 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
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel