GNU bug report logs - #13104
Extending automake rules w.r.t dependencies

Previous Next

To reply to this bug, email your comments to 13104 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Theophile Ranquet" <ranquet <at> lrde.epita.fr>
To: bug-automake <at> gnu.org
Subject: Extending automake rules w.r.t dependencies
Date: Thu, 6 Dec 2012 16:41:24 +0100 (CET)

[Message part 1 (text/plain, inline)]

Hi,

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

(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?)

The best solution we could come up with was to add these to
doc_bison_TEXINFOS, as follows, but this is a bit troublesome as it
causes the regeneration of all three filetypes whenever a
documentation is built, even when none is actually required (e.g. for
'make info' which uses .txt versions):

 doc_bison_TEXINFOS = \
   $(CROSS_OPTIONS_TEXI)                         \
   doc/fdl.texi                                  \
-  doc/gpl-3.0.texi
+  doc/gpl-3.0.texi                              \
+  $(FIGS_DOT:.dot=.eps)                         \
+  $(FIGS_DOT:.dot=.png)                         \
+  $(FIGS_DOT:.dot=.pdf)

If it is not possible to add custom dependencies to these Automake
rules, what whould you recommend doing?

FWIW, I have attached a diff showing the rules being overwritten by
the prior "solution".

Thanks!

[Makefile.diff (text/x-patch, attachment)]

Message #8 received at 13104 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> elliptictech.com>
To: Theophile Ranquet <ranquet <at> lrde.epita.fr>
Cc: 13104 <at> debbugs.gnu.org
Subject: Re: bug#13104: Extending automake rules w.r.t dependencies
Date: Thu, 6 Dec 2012 17:16:35 -0500

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/)

Message #11 received at 13104 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Nick Bowler <nbowler <at> elliptictech.com>
Cc: Theophile Ranquet <ranquet <at> lrde.epita.fr>, 13104 <at> debbugs.gnu.org
Subject: Re: 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

Message #14 received at 13104 <at> debbugs.gnu.org (full text, mbox):

From: "Theophile Ranquet" <ranquet <at> lrde.epita.fr>
To: "Nick Bowler" <nbowler <at> elliptictech.com>
Cc: Theophile Ranquet <ranquet <at> lrde.epita.fr>, 13104 <at> debbugs.gnu.org
Subject: Re: bug#13104: Extending automake rules w.r.t dependencies
Date: Fri, 7 Dec 2012 10:46:01 +0100 (CET)

> Hello,

Hi,

> 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.

We did something similar, with a little tweak because using three
variables seemed a bit of an overkill:

commit 476af12837af129d36b302e30789c549c85fdadb
Author: Theophile Ranquet <ranquet <at> lrde.epita.fr>
Date:   Tue Dec 4 16:09:24 2012 +0100

    doc: fix build dependencies

    * doc/local.mk: Avoid overwriting Automake's rules.

diff --git a/doc/local.mk b/doc/local.mk
index aaea996..cef4448 100644
--- a/doc/local.mk
+++ b/doc/local.mk
@@ -20,7 +20,14 @@ doc_bison_TEXINFOS =                            \
   doc/fdl.texi                                  \
   doc/gpl-3.0.texi

-TEXI2DVI = texi2dvi --build-dir=doc/bison.t2d
+# Cannot express dependencies directly on file names because of Automake.
+# Obfuscate with a variable.
+doc_bison = doc/bison
+$(doc_bison).dvi: $(FIGS_DOT:.dot=.eps)
+$(doc_bison).pdf: $(FIGS_DOT:.dot=.pdf)
+$(doc_bison).html: $(FIGS_DOT:.dot=.html)
+
+TEXI2DVI = texi2dvi --build-dir=doc/bison.t2d -I doc
 CLEANDIRS = doc/bison.t2d
 clean-local:
 	rm -rf $(CLEANDIRS)
@@ -123,10 +130,6 @@ EXTRA_DIST +=								\
   $(FIGS_DOT:.dot=.eps) $(FIGS_DOT:.dot=.pdf) $(FIGS_DOT:.dot=.png)
 SUFFIXES += .dot .eps .pdf .png

-doc/bison.dvi:  $(FIGS_DOT:.dot=.eps)
-doc/bison.html: $(FIGS_DOT:.dot=.png)
-doc/bison.pdf:  $(FIGS_DOT:.dot=.pdf)
-
 .dot.eps:
 	$(AM_V_GEN) $(MKDIR_P) `echo "./$@" | sed -e 's,/[^/]*$$,,'`
 	$(AM_V_at) $(DOT) -Gmargin=0 -Teps $< >$@.tmp



> Hope that helps,

It did, thanks!

Message #17 received at 13104 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: 13104 <at> debbugs.gnu.org
Subject: Re: bug#13104: Extending automake rules w.r.t dependencies
Date: Mon, 15 Jun 2020 18:56:34 -0600

Back on https://debbugs.gnu.org/cgi/bugreport.cgi?bug=13104 ...

    Date: Fri, 07 Dec 2012 10:04:15 +0100
    From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
    ...
    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.

I agree with the "ideally". Unfortunately, apparently no one, including
me, is anxious to undertake a project like that.

However, I can imagine a simpler method of getting the basic
functionality of adding dependencies to a given target: Define a new
command, say, AM_ADD_DEPS, which takes two arguments, a target name and
a list of dependencies. So,
  AM_ADD_DEPS(foo, bar baz)
would write
  foo: bar baz
into the Makefile.in, with no other effects.

Would that work? Would it be useful? Just a stray thought ... --thanks, karl.

Message #20 received at 13104 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: 13104 <at> debbugs.gnu.org
Subject: Re: bug#13104: Extending automake rules w.r.t dependencies
Date: Sun, 12 Jul 2020 18:37:00 -0600

My mistake, merely being able to add extra dependencies could be done by
target: $(SOME_VAR)
and use AC_SUBST to set SOME_VAR (thanks, Jim). But this does nothing to
solve the problem when target is a name that automake already has rules
for and thus does not allow overring.

Setting severity to wishlist ... -k

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.