[Top][All Lists]

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

AM_YFLAGS aren't used in the presence of per-target YFLAGS

From: Matt Turner
Subject: AM_YFLAGS aren't used in the presence of per-target YFLAGS
Date: Fri, 14 Sep 2012 19:51:03 -0700

In attempting to massage automake into doing what I want, I've found
what I consider to be some deficiencies in its handling of bison- and
flex-generated code. Here's one in particular.

=== AM_YFLAGS aren't used in the presence of per-target YFLAGS ===

Bison's -p flag specifies a prefix for a parsers' functions in order
to avoid naming collisions. For programs with multiple parsers this is
even more important. Take for instance the OpenGL Shading Language
compiler and associated preprocessor in Mesa. We'd like to pass -p
"glsl_parser_" to bison when generating the GLSL parser from
glsl_parser.yy and separately -p "glcpp_parser_" to bison when
generating the preprocessor parser.

So if our simplified _SOURCES variables were

libglsl_la_SOURCES = glsl_parser.yy glsl_lexer.ll ...
libglsl_la_LIBADD =

libglcpp_la_SOURCES = glcpp-parser.y glcpp-lexer.l ...

then we'd specify per-target YFLAGS as

libglsl_la_YFLAGS = -p "glsl_parser_"
libglcpp_la_YFLAGS = -p "glcpp_parser_"

This works fine, except that since we want to generate an associated
header for each of these, we may think that we could just specify
"AM_YFLAGS = -d" and have it applied to both targets. Unfortunately
when using per-target YFLAGS, the AM_YFLAGS aren't applied, which
doesn't seem to match up with the behavior of, for example, AM_CFLAGS
in the presence of per-target CFLAGS (where both are applied to the

To be clear, specifying per-target YFLAGS causes AM_YFLAGS to not be
used, whereas AM_YFLAGS are used without per-target YFLAGS. This is
unexpected and counter-intuitive to say the least.

I did not check whether this is also the case with LFLAGS, but it
would not surprise me.

Also in this scenario, specifying per-target YFLAGS causes the
generated code to be named libglcpp-la-glcpp-parser.c which isn't nice
looking for distribution. I suppose there are probably good reasons
for this, but #including "libglcpp-la-glcpp-parser.h" when your .y
file is named glcpp-parser.y is ugly and strange.

reply via email to

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