GNU bug report logs - #13928
foo_SOURCES containing unexpanded $(var) breaks with 'subdir-object' option active

Previous Next

Full log

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

From: Nick Bowler <nbowler <at> elliptictech.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 13928 <at> debbugs.gnu.org, peda <at> lysator.liu.se, bfriesen <at> simple.dallas.tx.us,
	Bert Wesarg <bert.wesarg <at> googlemail.com>, eblake <at> redhat.com, miles <at> gnu.org
Subject: Re: bug#13928: VPATH issues with subdir-objects (was: [PATCH 1/2]
	preproc: add support for relative names in included fragments)
Date: Mon, 11 Mar 2013 17:33:34 -0400

On 2013-03-11 21:55 +0100, Stefano Lattarini wrote:
[...]
>   - from Automake 2.0 onward, only enable the automatic dependency
>     tracking if GNU make is used; we can thus assume the presence
>     of the "-include" directive (which ignore non-existing files,
>     rather than punting), and its use will allow us to get rid of
>     the configure time machinery for the initial creation of .deps
>     directories (this has already been done in Automake-NG, and has
>     worked beautifully so far).
> 
> I think the approach described above is acceptable because automatic
> dependency tracking is important only for developers or power users,
> and those should be using GNU make anyway.

I can't say I'm a big fan of breaking the current wide-support of
automatic dependency tracking in Automake.  While not universal, the
automatic dependency tracking currently works with many different make
implementations (particularly those provided by the BSD flavours).

I also don't agree with the rationale that only developers and "power
users" need this feature.  The most obvious class of users who may need
this feature are those applying patches sent by a maintainer to test a
bug fix.  Particularly if those users are running on an exotic platform
without GNU make that the maintainer would not otherwise have access to.

Or users who want to run "git bisect" -- I've done this on packages with
buggy incremental builds before, and it's not a lot of fun.

Ideally, we should try to fix the bug before ripping out an
otherwise-working feature.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Previous Next

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