[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#7648: Automake yacc support, GNU bison, and non-standard generated h
From: |
Iain Nicol |
Subject: |
bug#7648: Automake yacc support, GNU bison, and non-standard generated headers |
Date: |
Tue, 9 Aug 2011 14:28:46 +0100 |
Hi,
Stefano Lattarini wrote:
> Hi Iain, thanks for the answer (and sorry for the delay).
No worries. Plus, I also tend to delay.
> [Iain Nicol wrote:]
>> One thing which did strike me: EXTRA_ might not be the best prefix
>> for YACC_HEADERS. If you do a ``make dist'' on a C Bison project
>> then of course zardoz.h is included in the dist tarball, which AFAICT
>> is GNU Coding Standards encouraged behaviour---presumably because
>> installing Bison used to be more difficult that it is these days. It
>> would be consistent for the YACC_HEADERS to also end up also in the
>> dist.
> I agree with what you say, but I don't see how this constitutes a
> counter-argument to the use of EXTRA_ as a prefix for YACC_HEADERS.
It probably isn't a counter argument. I'm thinking out loud, for better
or worse...
What I /was/ thinking is, because we may want these headers in the dist,
maybe the ``dist_'' prefix should be part of the variable name---at
least optionally. I wasn't sure if there is an EXTRA_dist_
construction, which was what I was trying to get at before.
Either way, given that SOURCES is ``SOURCES'' and not ``dist_SOURCES'',
it's not clear that the name of YACC_HEADERS should have to have
``dist_'' in it--even if the files automatically end up in the dist.
On that note, /do/ you think the headers should end up in the dist
automatically, or do you think the user should have to do this:
EXTRA_DIST += $(EXTRA_zardoz_YACC_HEADERS) ?
> Update: OTOH, quoting from the section "The Uniform Naming Scheme" of
> the automake manual:
> For each primary, there is one additional variable named by
> prepending `EXTRA_' to the primary name. This variable is used to
> list objects that may or may not be built, depending on what
> configure decides.'
> This doesn't fit very well with the situation we are talking about, so
> `EXTRA_foo_YACC_HEADERS' is not a great name after all ...
> Suggestions on how to change it are welcome.
I'll throw my only idea out there, with little idea of its suitability:
BUILT_ as a prefix, to make BUILT_YACC_HEADERS analogous to
BUILT_SOURCES.
But FWIW I can't see BUILT_ in the "Uniform Naming Scheme" manual
section. And then the manual says this about BUILT_SOURCES:
BUILT_SOURCES is actually a bit of a misnomer, as any file which must be
created early in the build process can be listed in this variable.
Moreover, all built sources do not necessarily have to be listed in
BUILT_SOURCES.
So maybe not.
> Which patch are you referring to exactly?
I saw a patch attached to this bug, bug #7648. (It's not a fix for the
main issue.) I think it was committed here:
<http://git.savannah.gnu.org/cgit/automake.git/commit/?h=ylwrap-refactor&id=06efe9c467768a25c374b5d47dc8f1412874352d>
It's less the patch and more the log. Before I read the log I hadn't
had obvious "aha" that Automake could be made to simultaneously match
either EXTRA_foo_YACC_HEADERS or EXTRA_foo_dist_YACC_HEADERS (or
whatever), well, if need be. I really am thinking out loud, you see ;).
Regards,
Iain