[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] src/preproc/refer/ in CVS.

From: Werner LEMBERG
Subject: Re: [Groff] src/preproc/refer/ in CVS.
Date: Tue, 24 Jul 2001 05:41:22 +0200 (CEST)

> I've just looked at configure and it searches for byacc and bison
> before defaulting to yacc.  You don't have bison either I guess?

I have bison, I have yacc -- but not byacc.  Maybe it's time to
install it...
> If all three work then isn't it OK to assume the machine compiling the
> source will have one of them?

OK, here is what Nelson Beebe writes about yacc:

>> ...
>>      These programs have been built, tested, and validated with two
>>      independent lexers (flex and lex), and three independent
>>      parser generators (bison, byacc, and yacc), using all
>>      available C and C++ compilers on these 11 UNIX systems for the
>>      1.04 release: 413 successful builds, and 49 failures.
>>      While the large number of successful builds is gratifying, the
>>      failures are potentially even more important if they can be
>>      traced to deficiencies in my code. Close examination of the
>>      build logs shows that they are not: they are entirely due to
>>      one of the following:
>>            * Code from lex/flex and/or bison/byacc/yacc which is
>>              not C++-compatible; there is no excuse for such vendor
>>              sloppiness, but it exists. C has had an ANSI/ISO
>>              Standard since December 1989, and the draft standard
>>              was stable at least two years before that, so the
>>              target language has been publicly defined for about a
>>              dozen years. All C-Standard-conforming code should
>>              compile without problems under C++ (barring use of C++
>>              reserved words).
>>            * Lack of compiler support for the non-standard stack
>>              memory allocator, alloca(), used in bison-generated
>>              code.
>>            * Internal compiler errors (e.g., lcc on NeXT and
>>              SGI IRIX 6.x systems).
>>            * Broken vendor-provided yacc (SGI IRIX 5.3).
>>            * Broken vendor-provided header file, alloca.h (pgCC).
>>              A bug report about this to the vendor, The Portland
>>              Group (, produced a prompt
>>              response with the following patch:
>>              ....
>> ...

Nelson has installed groff on a great variety of platforms, and the
code seems to work without problems.

> It just seems a bit of a kludge to ship yacc source but not expect
> it to be used and to have to keep both the pic, eqn, and refer *.y's
> and their *.cc's in step.

As soon as I get byacc I'll compare the output with the current files
in the CVS.  If the results are about to be identical, I'll remove the
affected CC files from the CVS.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]