#112 make fails on yacc command

Usability
closed-fixed
sfcb (1090)
5
2005-08-30
2005-05-17
No

metaxa sfcb $ make
yacc -p sfcQuery -d -o queryParser.c queryParser.y
usage: yacc [-dlrtv] [-b file_prefix] [-p
symbol_prefix] filename
make: *** [queryParser.c] Error 1

-----------------------

Above is the error message I get. If I check the man
page for yacc, I see there is no -o option for it.

I am using yacc-1.9.1 from
ftp://metalab.unc.edu/pub/Linux/devel/compiler-tools/

As I understand it, the -o option exists in byacc. If
byacc was the yacc meant to be used with sfcb, then it
should be a required dependency. I wonder if yacc in
general is a dependency in sfcb at all.

Discussion

  • Anonymous - 2005-05-30

    Logged In: YES
    user_id=230251

    What is the yacc version you are using ?

     
  • Renier Morales

    Renier Morales - 2005-06-13

    Logged In: YES
    user_id=660960

    I am using yacc-1.9.1 from
    ftp://metalab.unc.edu/pub/Linux/devel/compiler-tools/

     
  • Tyrel Datwyler

    Tyrel Datwyler - 2005-08-08

    Logged In: YES
    user_id=640104

    The -o option is a bison flag which is not compatible with
    yacc. Most systems use bison in place of yacc, and often
    replace yacc with a script that redirects execution to bison
    since bison recognizes all yacc options. We either need to
    explicitly require bison as a build requirement, or change
    the build to use only yacc comabatible options.

     
  • Tyrel Datwyler

    Tyrel Datwyler - 2005-08-24

    Logged In: YES
    user_id=640104

    Renier,

    The yacc package you are using is actually a very old
    version, from around 1997, of byacc. New versions (the
    latest being 1.9 20050813) support the -o flag.

     
  • Tyrel Datwyler

    Tyrel Datwyler - 2005-08-24

    Logged In: YES
    user_id=640104

    I recommend this defect be closed. Any modern Linux
    distrobution provides either byacc or bison as the yacc
    implemenation they ship with. Both of which support the -o
    option (byacc namely does so in current implementations).
    Futher, it is highly unlikely to find anyone using the
    original AT&T implemenation of yacc as both byacc and bison
    have proved themselves as better alternatives, and the fact
    that an original AT&T implementation proves difficult to
    come by.

     
  • Renier Morales

    Renier Morales - 2005-08-24

    Logged In: YES
    user_id=660960

    I think the fix for this bug is what tyreld recommended
    earlier, which is to require bison as a build requirement,
    or change
    the build to use only yacc comabatible options

    Gentoo has a yacc package for yacc, and a bison package for
    bison and a byacc package for byacc. It makes sense that if
    byacc is what is expected to exist, then to require this,
    since yacc still exist as yacc in other distributions.

     
  • Tyrel Datwyler

    Tyrel Datwyler - 2005-08-25

    Logged In: YES
    user_id=640104

    On closer inspection of the parser code it has come to my
    attention that there are bison specific declarations
    present. We have thus come full circle and must require
    bison as a build requirement.

    [side note]

    Inspection of the gentoo yacc package shows that it is the
    yacc-1.9.1 code from metalab.unc.edu. As I pointed out
    earlier this *not* AT&T yacc but an old byacc implementation
    (look at the README). Further, this old code base has not
    been touched since 1997. The maintained byacc package has
    been updated to be ANSI C compliant as well as performance
    tuned. Further, it meets the POSIX standard for yacc
    compatablility.

     
  • Tyrel Datwyler

    Tyrel Datwyler - 2005-08-29

    Logged In: YES
    user_id=640104

    Renier,

    The recently updated README reflects the fact that bison is
    a build requirement. Please close this defect.

    Thanks,

    Tyrel

     
  • Renier Morales

    Renier Morales - 2005-08-30

    Logged In: YES
    user_id=660960

    If bison is a build requirement, then it must be checked for
    in the ./configure script. That would fix this.

     
  • Tyrel Datwyler

    Tyrel Datwyler - 2005-08-30

    Logged In: YES
    user_id=640104

    The configure script contained an explicit check for bison.
    Aside from a "no" being displayed there was no obvious error
    message being generated to warn the user. I checked in a fix
    that will now generate an error and exit the configure
    script in the event the bison build requirment is not met.

    However, looking at Makefile.am I've noticed explicit calls
    to yacc. Further, the ylwrap script provided by the GNU
    buildtools will call yacc directly regardless of whether it
    is a wrapper for bison or byacc. This is problematic since
    automake generates the following rule which breaks the build
    if on my box if yacc points to byacc:

    .y.c:
    $(SHELL) $(YLWRAP) $< y.tab.c $@ y.tab.h $*.h y.output
    $*.output -- $(YACCCOMPILE)

     
  • Tyrel Datwyler

    Tyrel Datwyler - 2005-08-30

    Logged In: YES
    user_id=640104

    Further, inspection shows that ylwrap calls the correct
    executable. Namely, $YACC which is set to bison by the
    configure script. The broken build culprit is the explicit
    yacc call in the Makefile. I've replaced this with $(YACC)
    which is set to bison by the configure script.

     
  • Tyrel Datwyler

    Tyrel Datwyler - 2005-08-30

    Logged In: YES
    user_id=640104

    Reiner,

    I have verified the following:

    1.) If bison is not present the configure script exits with
    an error informing the user of the build requirement.

    2.) The Makefile contains no calls to yacc, but instead all
    calls are explicitly to bison.

    If this resolution meets your expectations can you please
    close this defect.

    Thanks,

    Tyrel

     
  • Renier Morales

    Renier Morales - 2005-08-30
    • status: open --> closed-fixed
     
  • Renier Morales

    Renier Morales - 2005-08-30

    Logged In: YES
    user_id=660960

    Tyreld fixed it. Thanks.

     
  • Viktor Mihajlovski

    Logged In: YES
    user_id=1198711

    Just to emphasize Tyrel's findings: Ylwrap has no support
    for multiple parsers/lexers per load module right now. So we
    will have to stay with the explicit invocations. I have
    slightly changed the invocations (using the LEX variable now
    as well).

     

Log in to post a comment.