Re: bison 1.875 vs. C++

[Laurence Finston]

On Thu, 15 Jul 2004, John Gatewood Ham wrote:

> Well, on the web page http://www.gnu.org/software/bison/bison.html#mailing
> it said this:  "To contact Bison community for help or general
> discussions, use help-bison AT gnu.org"  I am surprised to learn the
> developers of bison are not part of the bison community, but it would
> go a long way towards explaining how the current situation has come about.

That's not what I meant.  Nor do I speak for the Bison maintainers and
developers.
However, I know from my own experience that handling email is a fairly
time-consuming activity, so I think it's understandable that the
maintainers and developers concentrate on bug-bison, since there are a
number of users who can answer most questions.

>
> It appears you are requesting a patch.  I can do that this weekend.
>

> Do I post the patch here or on the bison-patches AT gnu.org mailing list?
>

I'm not requesting anything.  I rarely use OpenOffice, and never
in combination with Bison.  However, generally speaking, contributions
to GNU packages are very welcome.  There are matters of copyright that
have to be settled first, though.  I don't know how the Bison maintainers
handle this, so if you'd like to contribute a patch, please contact
them.

Laurence

> JGH
>
> On Thu, 15 Jul 2004, Laurence Finston wrote:
>
> > Hello John,
> >
> > This list is primarily for users of Bison to help each other.  If you want
> > to contact the maintainers and developers, you'll have better success if
> > you use address@hidden
> >
> > I'd like to ask you to consider that GNU Bison is
> > developed by volunteers in their free time.  It is very much the exception
> > that the development of a GNU package receives any financial support.  The
> > GNU Public License also specifically states that "... the copyright
> > holders and/or other parties
> > provide the program `as is' without warranty of any kind, either expressed
> > or implied, including, but not limited to, the implied warranties of
> > merchantability and fitness for a particular purpose.  The entire risk as
> > to the quality and performance of the program is with you."
> >
> > So if you want a particular feature to work, be prepared to be asked
> > if you want to volunteer.
> >
> > Laurence Finston
> > GNU 3DLDF maintainer
> > http://gnu.org.software/3dldf/LDF.html
> >
> > On Thu, 15 Jul 2004, John Gatewood Ham wrote:
> >
> > > Hello,
> > >
> > >     The bison 1.875 version does not work with OpenOffice 1.1.2.
> > > I was able to create a modified skeleton file that works by
> > > just removing the macro stuff at yyerrlab1.  I see that bison
> > > will let me specify a -S option to specify an alternate skeleton.
> > > However, the build system for OpenOffice is impenetrable and
> > > hopelessly convoluted, so modifying every call of bison in their
> > > stuff is not practical.  I was wondering if there is some BISON_SKELETON
> > > environment variable I can set that gives the full file name for
> > > the skeleton to use [BISON_SKELETON would have the same argument as
> > > the -S option]?  I could not find much in the man page or info file,
> > > so I decided to post here.  I see many times in the archives people
> > > say run the alpha-test version.  By definition an alpha-test version is
> > > even less stable than a release version.  I need more stability, not
> > > less.  If the alpha-test version is more stable and works 'out of the
> > > box', then it should be released and then the problem is solved to
> > > everyone's satisfaction.
> > >
> > > I realize it is probably OpenOffice's fault, but I'm looking
> > > for a working solution and other applications are breaking with
> > > bison 1.875, so this seems to be an issue with what people expect
> > > from bison compared to what it currently delivers.  If there will not
> > > be any official release with a working [in terms of all the normal
> > > apps build with it] skeleton file, perhaps you could release a
> > > 1.876 version that has only a change to support an environment variable
> > > to use for an alternate skeleton file, and an alternate skeleton file
> > > that doesn't have that macro stuff at yyerrlab1.  With the environment
> > > variable approach, the user would not need to modify any build systems;
> > > they just set the environment variable and export it before starting a
> > > normal build.
> > >
> > > If such an environment variable already exists, please document it.
> > >
> > > JGH
>