mapparser.c does not compile in 5.0 branch

[warmerdam]

Building MapServer from an svn checkout of the 5.0 branch on 64bit linux (gcc 3.4.5) I get:

mapparser.c:6: error: parse error before string constant
mapparser.c:6: warning: type defaults to `int' in declaration of `__IDSTRING'
mapparser.c:6: warning: data definition has no type or storage class
y.tab.c: In function `yyparse':
y.tab.c:397: warning: implicit declaration of function `yylex'
y.tab.c:436: warning: implicit declaration of function `yyerror'
make: *** [mapparser.o] Error 1

It appears that mapparser.c was regenerated after the 5.0 release with a different version of bison than usual (r6899).

I'm able to build ok by deleting mapparser.c/mapparser.h and regenerating but I think we need a maximally "safe" version in subversion.

[tbonfort]

also fails on regular x86

The current version was created by Steve on OSX. I posted about it a month ago on ms-dev, and Steve said to just regenerate it. Didn't commit it either as there seems to be some magic behind that file ;)

[sdlime]

The bison generated files don't seem to be OS neutral. If we commit linux generated versions they likely won't work on OS X and will require the same delete/rebuild. However, there seem to be less issues with files generated on linux so perhaps that should be our reference OS?

Steve

[warmerdam]

Steve,

Whatever the specific version of bison was that we were using in the past seemed to produce safe cross platform source code. I think we need to get back to generating the version for in subversion (and release tarballs) using that version. Do you still have access to the bison you were using previously?

[sdlime]

I can't get to the cvs machine at the UMN anymore but I'm almost positive it was 1.875. I've not been using any of the 2.x releases.

Steve

[sdlime]

It may be that my OS X version of bison is out-of-date but I could have sworn I'd updated it. -Steve

[warmerdam]

Steve,

Looking at the revision it appears previously the parser was built with bison 1.35.

/* A Bison parser, made from mapparser.y 
   by GNU bison 1.35.  */ 

I suspect you are using to recent (or perhaps to mac specific) a version. If necessary, we could install bison 1.35 on download.osgeo.org and regenerate the parser there when needed.

[sdlime]

But it's the current version is SVN that's causing the problems correct? So 1.35 should probably be avoided then. Let me check on my home machine and report back tonite.

Steve

[warmerdam]

Steve,

The bit quoted was removed in r6899, so it suggests we were previously using bison 1.35.

[sdlime]

Macs come with old versions of a lot of things, including bison- it's 1.35. Should I commit a parser generated by 1.875 and see if that helps? I wish I could get at the old CVS box to check for sure. I'll ping Tom.

Steve

[warmerdam]

Steve,

OK, go ahead and try 1.875. We can test it on a few platforms fairly quickly.

[dmorissette]

FYI r6061 from Steve says: "Added lexer/parser output from flex (v. 2.5.31) and bison (v. 1.35) to the repository." ... and looking at the source of that revision it is indeed 1.35.

So 1.35 should be fine. Perhaps it's the mac-specific version that's the issue?

Note that in r6373 I committed a version based on bison 2.3 (Linux) and a few weeks later Steve committed r6498 based on bison 1.35 and we heard no complaints in both cases. Steve, do you know what may have changed at your end between your r6498 and r6899 commits? Were both done from the same machine?

[sdlime]

Replying to warmerdam:

Steve,

OK, go ahead and try 1.875. We can test it on a few platforms fairly quickly.

I committed late yesterday afternoon.

Steve

[sdlime]

Replying to dmorissette:

FYI r6061 from Steve says: "Added lexer/parser output from flex (v. 2.5.31) and bison (v. 1.35) to the repository." ... and looking at the source of that revision it is indeed 1.35.

So 1.35 should be fine. Perhaps it's the mac-specific version that's the issue?

Note that in r6373 I committed a version based on bison 2.3 (Linux) and a few weeks later Steve committed r6498 based on bison 1.35 and we heard no complaints in both cases. Steve, do you know what may have changed at your end between your r6498 and r6899 commits? Were both done from the same machine?

I think that committing any "generated" files from mac os should probably be avoided. I gotta think that's the problem. I haven't had any problems on SuSE with the mac output but it seems problematic. My home machine is very stable so I don't know what could have changed between the revisions you mention. Same box, same bison version. However, the change at r6899 was actually a change to the parser code (mapparser.y) which is rare so perhaps that was the problem.

[warmerdam]

I have tested the mapparser.c/h in trunk (r7023) on several platforms and it seems fine. Steve, could you commit a similarly generated mapparser.c/h in the 5.0 branch where the problem is?

[sdlime]

Updated in 5.0 branch.

Steve

[warmerdam]

Steve, this seems to address things for me. I think the bug report can be closed.

[dmorissette]

For the record, the 5.0 branch update was in r7028.