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

[Matt Turner]

On Sat, Sep 15, 2012 at 12:56 AM, Stefano Lattarini
<address@hidden> wrote:
> 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.

Indeed, you are correct all around. My mistake and apologies.

>> 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

Interesting. I will check this out.

Thanks a lot for your time.

Matt