regress failure on postgresql 9.0 on windows

[robe]

I guess I've been zoned out, just noticed winnie is screaming when she tries to regress on 9.0 since strk's change in

r11175

psql:c:/jenkins/postgis/branches/2.1/regress/00-regress-install/share/contrib/postgis/postgis.sql:697: ERROR:  syntax error at or near "FOR"
LINE 16:  OPERATOR        13       <-> FOR ORDER BY pg_catalog.float_...

not sure why debbie isn't complaining. Perhaps only an issue on windows with order of includes or something or I have a dirty file somewhere.

[robe]

I'm think this might have something to do with liblwgeom.a and liblwgeom.la and .h are being created in msys/local/lib. I just deleted them. This was the same issue I had with shp2pgsql-gui suddenly starting to fail after pramsey made an unrelated change.

I'm rerunning regress and will close this out if this fixes the issue, though not sure how to stop this in future. Its really bothersome that the files don't always get installed in msys/local/lib, and if I delete the files they don't usually come back on next run.

[strk]

The change in r11175 has nothing to do with installation path of .a .la and .h files.

[robe]

I know that. Neither did pramseys. It just seemes to happen when major changes in lwgeom or include locations changing. I'm just not sure how files end up being created there and why they don't always get created is my point.

[robe]

Well anyway clearing that folder doesn't help. I'll test locally in a bit, but it seems somehow your change screwed up (at least on mingw64) ability for it to differentiate between PostgreSQL 9.0 and above, because the install failure is happening because ORDER BY support is only valid for PostgreSQL 9.1+ since it relies on KNN logic introduced in 9.1 but its being left in for 9.0.

  OPERATOR        13       <-> FOR ORDER BY pg_catalog.float_...

Personally. I DON'T like this change you made on postgis.sql.in.c and other files that require c preprocessing.

Those files have C defines in it and to me they should have a .c extension to distinguish them from other .sql.in files that say go thru your perl preprocessor.

[strk]

Alright, it could then have to do with SQLPP, can you check it's value in postgis/Makefile ?

$ grep ^SQLPP postgis/Makefile 
SQLPP = /usr/bin/cpp -traditional-cpp -P

Do you have cpp installed ?

[strk]

Something to look at is also here: ​http://sourceforge.net/projects/sqlpp/

[strk]

Sorry, I meant this one: ​http://search.cpan.org/~karasik/bin-sqlpp-0.06/bin/sqlpp

[strk]

Another thing, cpp(1) manual talks about a -x switch that can be used to specify the language, can you check if adding -x c fixes the issue for you ?

[strk]

Ah, final thing (I forgot this one). The ./configure script now also check for GPP (the Generic Pre Processor), but prefers cpp when found. I'd be curious to know if GPP would work fine instead.

Looking forward to the generated files and to account info to come and see what the issue is.

[strk]

r11195 adds the -x c switch to the cpp call, does it change anything ?

[robe]

No. You can take it out. I think the issue is that the

postgis.sql.in is being overwritten each call.

So the cpp stuff is working fine, since if I switch order of regress, 9.0 passes and the others fail.

[robe]

Nevermind. I'm pretty sure it was because for some reason the svn update did not delete the old postgis.sql.in and so didn't pull the new one.

I'll double-check the svn pull logic. It may be different from what I have on debbie. Deleting the file which forces the pull I think fixed the issue, so you can take out that -x c