bug-automake
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]