On Sat, Sep 15, 2012 at 12:56 AM, Stefano Lattarini <stefano.lattar...@gmail.com> 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
