On 09/15/2012 04:51 AM, Matt Turner wrote:
> 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 ===
>
That is by design, and consistent with what is done for other *FLAGS
variables; it is also documented:
http://www.gnu.org/software/automake/manual/automake.html#Flag-Variables-Ordering
In particular, note the following sentences:
We will mostly discuss CPPFLAGS in our examples, but actually the answer
holds for all the compile flags used in Automake: ... LFLAGS, ... YFLAGS.
...
Automake always uses two of these variables when compiling C sources files.
When compiling an object file for the mumble target, the first variable will
be mumble_CPPFLAGS if it is defined, or AM_CPPFLAGS otherwise. The second
variable is always CPPFLAGS.
...
Note that listing AM_CFLAGS in a per-target CFLAGS variable is a common
idiom
to ensure that AM_CFLAGS applies to every target in a 'Makefile.in'.
> 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).
>
No, they are not AFAICS. If they are, it's a bug. Could you send a
minimal test case reproducing that behaviour of CFLAGS? Thanks.
> 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.
>
It's documented and by design. The behaviour is indeed required to cater
to the situation where you have an option in $(AM_YFLAGS) that you don't
want applied to, say, a single 'foo.y' file.
> I did not check whether this is also the case with LFLAGS, but it
> would not surprise me.
>
Yes it is; again, by design.
> 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,
>
Yes:
<http://www.gnu.org/software/automake/manual/automake.html#Renamed-Objects>
albeit I sympathize with your distaste in this case.
> but #including "libglcpp-la-glcpp-parser.h" when your .y
> file is named glcpp-parser.y is ugly and strange.
>
You might de-uglifying the names a bit using the '_SHORTNAME' trick:
<http://www.gnu.org/software/automake/manual/automake.html#index-maude_005fSHORTNAME-484>
HTH,
Stefano
