[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13104: Extending automake rules w.r.t dependencies
From: |
Nick Bowler |
Subject: |
bug#13104: Extending automake rules w.r.t dependencies |
Date: |
Thu, 6 Dec 2012 17:16:35 -0500 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hello,
On 2012-12-06 16:41 +0100, Theophile Ranquet wrote:
> I am seeking advice for a workaround of what seems like a limitation
> in Automake (1.12.2).
>
> We have recently added figures to Bison's documentation. These figures
> are included by our texinfo source by using "@image", which requires
> different image formats depending on what we want to produce. For
> convenience's sake, these figures are generated from Graphviz DOT
> files, so we tried adding the following to our doc/local.mk:
>
> doc/bison.dvi: $(FIGS_DOT:.dot=.eps)
> doc/bison.html: $(FIGS_DOT:.dot=.png)
> doc/bison.pdf: $(FIGS_DOT:.dot=.pdf)
>
> However, these overwrite Automake's rules. This seems a bit similar,
> in that regard, to the issue discussed here:
> http://lists.gnu.org/archive/html/automake/2012-11/msg00015.html
The usual workaround to add prerequisites to an automake-generated
rule is to use a one-off make variable for the target name. For
example,
doc_bison_dvi = doc/bison.dvi
$(doc_bison_dvi): $(FIGS_DOT:.dot=.eps)
and so on. Automake does a simple string comparison of the target name
to decide whether or the generated rule is overridden, so using a
variable will hide the "real" target name from this check. Note that
this is only appropriate for rules with no commands.
> (Note that in another branch we are using multiple Makefiles, and in
> that branch adding the previous lines to our doc/Makefile.am has the
> desired effect, though I am not sure why... is this a bug or a
> feature?)
Hard to say without looking a concrete example, but the most likely
explanation is that the Automake-generated rules are different in the
recursive case, such that your custom rules don't actually override
anything.
Hope that helps,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)