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

[Stefano Lattarini]

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