[postgis-devel] Re: sql files proliferation

strk strk at keybit.net
Wed Mar 3 08:13:30 PST 2004


I've updated the Makefile so to use shell redirection
to produce postgis_new.sql
Any other tester there ?
To test: make postgis_new.sql <- and try the output

--strk;

On Mon, Mar 01, 2004 at 03:19:58PM +0100, strk wrote:
> pramsey wrote:
> > Confusingly, I have yet to find *any* way to call cpp that works. In 
> > fact, it does not appear to work the way the man page says it should... 
> > it resolutely refuses to write an output file.
> > Still trying.
> > P.
> 
> Does it write to stdout ?
> I don't see any problems in using shell redirects...
> --strk;
> 
> > 
> > On Sunday, February 29, 2004, at 02:43 PM, strk wrote:
> > 
> > > 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
> > > _______________________________________________
> > > 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
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel



More information about the postgis-devel mailing list