[Top][All Lists]

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

Re: AM_V_GEN - better docs

From: Stefano Lattarini
Subject: Re: AM_V_GEN - better docs
Date: Fri, 12 Nov 2010 21:19:01 +0100
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Friday 12 November 2010, Ralf Wildenhues wrote:
> Hello Patrick, Miles,
> * Miles Bader wrote on Fri, Nov 12, 2010 at 09:00:55AM CET:
> > Patrick Rutkowski <address@hidden> writes:
> > > I don't get from that page how to apply to all my $(CC) build
> > > commands, and I really want to quiet down this very messy "make"
> > > output I now have.
> *snip explanations*
> Thanks.  A doc change to improve the situation here would be nice;
> any volunteers?
I might give it a try (not right now); but I'll probably need some
guidance, as I'm not well up on the issue.

> For example, the silencing stuff could be part of
> a new section somewhere between the "Miscellaneous" and the "Not
> Enough" nodes, and it could treat `make -s', `make >/dev/null || make'
> and other tricks as well as a discussion of silent-rules and maybe even
> the tradeoffs mentioned in automake/lib/am/
> (There is no need that a patch does all of this, just one step would
> be nice already.)
> > > The doc page there doesn't even suggest where to look to learn how
> > > to apply it to your build.
> > 
> > It does, kinda, but maybe it doesn't go far enough;
> Yes, but I agree that it's also still fairly obscure.
> Especially the `make V=1' part probably cannot be documented
> too prominently.
> [...]
> > Maybe it would be good to specify what the should be done to make it
> > default to _on_, e.g.:
> > 
> >   "+ To enable silent-rules by default, specify an argument of "yes"
> >      to AM_SILENT_RULES, i.e., add "AM_SILENT_RULES([yes])" to the
> > file"
> > 
> > [I know that because somebody else posted it on this list recently :]
> We've intentionally not documented that yet, because we weren't sure
> whether it's a good idea having this functionality.  At least some
> distro maintainers would be more happy to see less bug reports with too
> little data because of this.
> It might be time to reconsider this decision.
If we document it, we should at least advise against it IMHO.


reply via email to

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