[postgis-devel] sql.in.c do we like not like?

Paragon Corporation lr at pcorp.us
Thu Mar 21 23:03:39 PDT 2013

> The only problem I've seen so far with dropping the .c extension is with
some C preprocessors NOT behaving correctly. Possibly fixed by adding a ``-x
c'' switch to 
> the invocation (can someone with that problem check this ?)

> I would recommend reverting this commit.

> I will if we don't figure out a workaround. I'm available to take a look
directly on the machines having the problem, please send me account info for

I still say we put back the .c suffix.  Just because its clearer it goes
thru a c preprocessor and not all .sql.in files do.

So have to say as dustymugs and others -- +1 for putting the .c back
regardless of even if you can make Winnie happy again with your current

> We're already overriding that rule in our Makefile:

>   # Borrow the $libdir substitution from PGXS but customise by adding the
version number
>  %.sql: %.sql.in
>    $(SQLPP) -I../libpgcommon $< | grep -v '^#' | \
>    $(PERL) -lpe
VERSION@'g" > $@

The PGXS issues is tricky because they made changes in 9.1 to introduce the
module_big/not big and just because we override some settings now doesn't
mean we will in the future. In fact I think we have some overriding that may
need to be pulled out after 9.0 becomes legacy. (or was it 8.4 Mark?)
So going by "BUT we are overriding anyway"  doesn't seem very forward
thinking to me. The whole extension thing in 9.3 is also supposed to
introduce a lot of changes like non-local extensions and so forth.

This note from Mark:
> "Also in future, build changes like this should be discussed on
postgis-devel first and not just blindly committed."

To be fair to strk he did bring it up:

and Mark -- you even responded :)


And I responded

But strk -- I think we may need to support MS VC in future so I don't want
to make the future support more difficult than it needs to be.  I haven't
tested on our Windows 2012 box yet, but that platform has a lot of changes
that I fear may behave very differently from the other windows versions and
may require us to use the MS toolchain.


More information about the postgis-devel mailing list