automake
[Top][All Lists]
Advanced

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

Re: [RFC] Docs: document silent make rules in a new chapter


From: Ralf Wildenhues
Subject: Re: [RFC] Docs: document silent make rules in a new chapter
Date: Sat, 20 Nov 2010 09:38:23 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

* Stefano Lattarini wrote on Thu, Nov 18, 2010 at 09:22:48PM CET:
> On Thursday 18 November 2010, Nick Bowler wrote:
> > On 2010-11-18 20:31 +0100, Stefano Lattarini wrote:
> > > address@hidden @code{AM_V_GEN}
> > > address@hidden FIXME: wouldn't $(AM_V_SILENT) be clearer?  Should we 
> > > deprecate
> > > address@hidden $(AM_V_at)?  It should be kept for backward-compatibility, 
> > > of
> > > address@hidden course.
> > 
> > AM_V_GEN is a long enough name as it is; AM_V_SILENT would be even worse
> > in this regard.
> > 
> > AM_V_at is very useful for targets which have multiple commands.  It's
> > not that interesting to see "GEN foo.bar" five times in a row.
> > 
> There's probably a misunderstanding here; I was suggesting to rename
> `AM_V_at' to `AM_V_SILENT', for clarity; and deprecate *only* the old
> name `AM_V_at'.  Does my proposal make sense now?

It makes sense, but it's a long name.  It's a close call I'd say but
I wouldn't want to deprecate AM_V_at, simply because it is shorter.
Other renaming suggestions have been made before, see e.g. this thread:
<http://lists.gnu.org/archive/html/bug-automake/2010-04/msg00001.html>

But I'm quite hesitant to do any renames at all unless there is a clear
advantage.  Automake has had a slightly bad reputation in the past for
not being backward compatible, and I wouldn't want that to return.  (And
I don't like overly verbose makefiles with lots of duplication either.)

Cheers,
Ralf



reply via email to

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