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 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 compile). 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.
