bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13104: Extending automake rules w.r.t dependencies


From: Stefano Lattarini
Subject: bug#13104: Extending automake rules w.r.t dependencies
Date: Fri, 07 Dec 2012 10:04:15 +0100

Hi Theophile, nick.

On 12/06/2012 11:16 PM, Nick Bowler wrote:
> 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.
>
Yeah, a long-standing behaviour, but one that I've never liked.

Ideally we could improve the makefile parser to check whether a
target has an associated recipe, and only in that case make it
override a built-in (or a previous user-defined) target; in the
other cases, it should be just considered a declaration of extra
dependencies.  After all, that is how (GNU) make itself behaves.

This is something to consider for Automake 1.14 (which will only
be released several months from now, at best).  Patches would be
extremely welcome :-)

In the meantime ...

>> 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.
>
... I'd follow this suggestion from Nick, which is absolutely correct.

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

Thanks,
  Stefano





reply via email to

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