GNU bug report logs - #8326
can't override dvi: target, or others with -local

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#8326: closed (can't override dvi: target, or others with -local)
Date: Tue, 29 Mar 2011 10:08:01 +0000

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

Your message dated Tue, 29 Mar 2011 12:07:22 +0200
with message-id <20110329100722.GC1536 <at> gmx.de>
and subject line Re: bug#8326: can't override dvi: target, or others with -local
has caused the GNU bug report #8326,
regarding can't override dvi: target, or others with -local
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
8326: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8326
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: karl <at> freefriends.org (Karl Berry)
To: bug-automake <at> gnu.org
Subject: can't override dvi: target, or others with -local
Date: Wed, 23 Mar 2011 00:21:56 GMT

Aside from the discussion in #8289 about alternatives to the hardwired
make dvi being run by make distcheck, there seems to be another problem,
namely putting a simple
dvi:
in a Makefile.am doesn't work to override the default rule. I get an
error like this:

  doc/Makefile.am:12: user target `dvi' defined here...
  automake: ... overrides Automake target `dvi' defined here
  doc/Makefile.am:12: consider using dvi-local instead of dvi

Looking for the code that's enforcing this, I see in Rule.pm around line
this comment:
	      # -am targets listed in %dependencies support a -local
	      # variant.  If the user tries to override TARGET or
	      # TARGET-am for which there exists a -local variant,
	      # just tell the user to use it.

But dvi-local does not suffice for the case at hand; that is, it can't
be used to avoid rebuilding the dvi, as far as I can see.  Certainly
merely adding dvi-local: does nothing in particular.  Is there another
way?

(Aside: I'm just curious, what can dvi-local actually be used for?
If there's a known use for it, I suggest mentioning it in the doc.)

As far as I can see, this behavior contradicts the documentation (node:
Extending), which simply says:

   * As far as rules are concerned, a user-defined rule overrides any
     `automake'-defined rule for the same target.

So my report is to suggest implementing that :).  Perhaps there should
be a warning in case of such overrides, but a fatal "you can't do that"?
Else the doc should be changed.

At any rate, if there's a workaround to get a clean make distcheck with
a PDF-only manual with the currently released automake, we'd like to know.

Thanks,
Karl

[Message part 3 (message/rfc822, inline)]

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 8326-done <at> debbugs.gnu.org, Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#8326: can't override dvi: target, or others with -local
Date: Tue, 29 Mar 2011 12:07:22 +0200

Hi Karl, Stefano,

* Stefano Lattarini wrote on Wed, Mar 23, 2011 at 09:28:52PM CET:
> On Wednesday 23 March 2011, Karl Berry wrote:
> > (Aside: I'm just curious, what can dvi-local actually be used for?
> > If there's a known use for it, I suggest mentioning it in the doc.)
> >
> If there is a known use, I don't know it; sorry!

Well, say I have a LaTeX document and my own rules to build it.  I want
DVI output of it to be available through 'make dvi', in addition to
Texinfo sources that also produce some DVI output (through the automake-
generated rules).  Then I write

dvi-local: foo.dvi

foo.dvi: ...
        ...

Generally, the *-local rules are the default way to extend targets for
which automake provides rules.  They all work the same way.  Nothing
fancy here, but definitely useful.

> That's already implemented (well, almost -- it's not true for few special
> targets, like `all' and `check'; maybe we should fix this inconsistency?)

Yes; I actually have worked on these two targets (after it came up in
the gnu make discussions with Xan Lopez elsewhere) but am not done yet.
They are a bit nontrivial to fix.


I'm closing this bug as it seems to have been cleared up.

Thanks,
Ralf

Previous Next

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