Re: bison 2.6.2 generates incompatible header file

[Akim Demaille]

Hi Frank,

Le 18 oct. 2012 à 18:52, Frank Heckenbach a écrit :

> We do compile our Bison output with g++ (yes, we should probably use
> the C++ skeleton, but we haven't gotten around to it yet),

I'd be happy to give a hand, and get some feedback
about it.

> and we
> don't use extern "C" -- in fact we use two different parsers in one
> executable and we put them in different C++ namespaces to avoid
> conflicts. (After the recent changes, this may no more be necessary
> as I understand, we'll have to check this after an upgrade …)

Indeed, if you want both to be in the same namespace, %define api.prefix
should do what you want.

Note that the C++ output supports "%define namespace", in
which the generated code is put.

> Currently we have in our *.y:
> 
> #define IN_BISON
> 
> and in our common header:
> 
> #ifndef IN_BISON
> int yyparse (params);
> #endif
> 
> IIRC, with earlier Bisons, it worked without the #ifndef, now it
> produces a duplicate declaration, so I suppose that's the relevant
> change in Bison and our workaround.
> 
> So I guess what this means is (a) blindly applying extern "C" would
> be wrong and (b) the situation is currently not nice, but acceptable
> (to us) with the above workaround, but at least that's temporary --
> after dropping support for older Bisons,

What is your policy on this regard?  When do you allow to rise
the %require'd version of Bison?  (actually, currently I see
none in 
http://csound.git.sourceforge.net/git/gitweb.cgi?p=csound/csound5.git;a=blob;f=Engine/csound_orc.y;h=259a4cbe6fd3873120513678f34b936103d2d43d;hb=HEAD)

> we won't have to declare
> yyparse at all which is (slightly) better than always having to
> declare it as it was before.

Yes, indeed.

Can the version of Csound compiled by Debian be changed easily to
compile cleanly with Bison 2.6?