GNU bug report logs - #12860
avoiding ‘check-recursive’

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12860 in the body.
You can then email your comments to 12860 AT debbugs.gnu.org in the normal way.

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

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

From: Thien-Thi Nguyen <ttn <at> gnuvola.org>
To: bug-automake <at> gnu.org
Subject: avoiding ‘check-recursive’
Date: Sun, 11 Nov 2012 08:24:37 +0100

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

In GNU Serveez, there are many subdirectories, but only one (test/)
that supports "make check" (w/ var ‘TESTS’ et al).  Thus, top-level
invocation of "make check" needlessly recurses, a grating annoyance.

I'd thought to arrange for top-level "make check" to simply redirect
into test/ by using ‘check-local’, but that failed.  Please see:

http://git.savannah.gnu.org/cgit/serveez.git/commit?id=f504730d3f

for details and the suboptimal workaround.  Am i missing something?

-- 
Thien-Thi Nguyen ..................................... GPG key: 4C807502
.                  NB: ttn at glug dot org is not me                   .
.                 (and has not been since 2007 or so)                  .
.                        ACCEPT NO SUBSTITUTES                         .
........... please send technical questions to mailing lists ...........

[Message part 2 (application/pgp-signature, inline)]

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Thien-Thi Nguyen <ttn <at> gnuvola.org>
Cc: 12860 <at> debbugs.gnu.org
Subject: Re: bug#12860: avoiding ‘check-recursive’
Date: Sun, 11 Nov 2012 10:11:51 +0100

severity 12860 wishlist
tags 12860 wontfix
close 12860

Hi Thien-Thi.

On 11/11/2012 08:24 AM, Thien-Thi Nguyen wrote:
> In GNU Serveez, there are many subdirectories, but only one (test/)
> that supports "make check" (w/ var ‘TESTS’ et al).  Thus, top-level
> invocation of "make check" needlessly recurses, a grating annoyance.
> 
> I'd thought to arrange for top-level "make check" to simply redirect
> into test/ by using ‘check-local’, but that failed.  Please see:
> 
> http://git.savannah.gnu.org/cgit/serveez.git/commit?id=f504730d3f
> 
> for details and the suboptimal workaround.  Am i missing something?
> 
If you want to avoid recursion, you should use a non-recursive Makefile.
GNU packages like Coreutils, Bison and Automake itself already use such
a setup in their build system, with no problem that I know of.

The current behaviour of the '*-recursive' targets is deeply entrenched
in the Automake implementation and design, and I have no plans to
change it.  I'm thus closing this report as "Won't Fix", sorry.

Best Regards,
  Stefano

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Thien-Thi Nguyen <ttn <at> gnuvola.org>
Cc: 12860 <at> debbugs.gnu.org
Subject: Re: bug#12860: avoiding ‘check-recursive’
Date: Sun, 11 Nov 2012 23:35:02 +0100

On 11/11/2012 08:40 PM, Thien-Thi Nguyen wrote:
> () Stefano Lattarini <stefano.lattarini <at> gmail.com>
> () Sun, 11 Nov 2012 10:11:51 +0100
> 
>    If you want to avoid recursion, you should use a non-recursive
>    Makefile.  GNU packages like Coreutils, Bison and Automake itself
>    already use such a setup in their build system, with no problem that
>    I know of.
> 
> I want to avoid recursion for "make check" only.  For everything else,
> recursion is desirable and appreciated.  Is there any way to do that?
>
Nope, sorry.

> If not, perhaps the documentation about foo-local targets "supplanting"
> Automake-generated foo targets should mention that such supplanting has
> limits, one of which is that it cannot be used to avoid recursion.
>
Actually, "foo-local" is expected to *extend*, not supplant, "foo"; and
that is a good design IMHO: otherwise you might have to re-implement the
recursion yourself every time you define a "foo-local" target in a
non-leaf Makefile.  Is there some wording in the manual that didn't make
clear this to you?  If yes, we might indeed want to fix such misleading
wording

> That way, at least, we can make progress to avoid this question
> re-arising.
> 

Thanks,
  Stefano

Previous Next

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