RFC: Patches to enhance automake support for silent-rules

Hi all, In order to make automake builds quieter when building with the "silent-rules" option, I made some patches that do this. Before spending the time figuring out how to write tests for these I would like to see if there was any interest in doing this. The patches are up on my gith

Re: Enhancing automake support for silent-rules

> %SILENT% doesn't work in any of the places I tried. I'm speculating that > this is because it's substituted too early. I see it being used in a few > places (eg. lib/am/library.am), but those rules are full of other %NAME% > strings. Different files will use different substitutions. For SILENT to

Re: Enhancing automake support for silent-rules

On 7 June 2013 23:10, Gavin Smith wrote: > On Fri, Jun 7, 2013 at 2:55 PM, Darren Garvey > wrote: > > Hi all, > > > > I've been trying to make a large automake-generated project I work on > build > > quieter. While there is some support for "silent-r

Re: Enhancing automake support for silent-rules

On Fri, Jun 7, 2013 at 2:55 PM, Darren Garvey wrote: > Hi all, > > I've been trying to make a large automake-generated project I work on build > quieter. While there is some support for "silent-rules", there are several > places where automake templates* don't

Enhancing automake support for silent-rules

Hi all, I've been trying to make a large automake-generated project I work on build quieter. While there is some support for "silent-rules", there are several places where automake templates* don't silence themselves, which I'd like to rectify. I have made several chan

Re: CC $sourcebasename-$sourcebasename.o displayed during silent rules build

On Wed, May 9, 2012 at 12:09 PM, Stefano Lattarini wrote: > This is expected, since the use of per-target compilation flags causes > the generated object files to be renamed; see: > Good, I was worried that I was doing s

Re: CC $sourcebasename-$sourcebasename.o displayed during silent rules build

BS) $(LDADD) > TestLowLatencyData1_CFLAGS = $(PTHREAD_CFLAGS) $(AM_CFLAGS) > TestLowLatencyData2_LDADD = $(PTHREAD_LIBS) $(LDADD) > TestLowLatencyData2_CFLAGS = $(PTHREAD_CFLAGS) $(AM_CFLAGS) > TestLowLatencyData3_LDADD = $(PTHREAD_LIBS) $(LDADD) > TestLowLatencyData3_CFLAGS = $(PTHREAD_CFLAG

CC $sourcebasename-$sourcebasename.o displayed during silent rules build

) TestLowLatencyData3_LDADD = $(PTHREAD_LIBS) $(LDADD) TestLowLatencyData3_CFLAGS = $(PTHREAD_CFLAGS) $(AM_CFLAGS) endif then when building with silent rules, the codes that are linked against libpthread are displayed as follows: CC TestLowLatencyData1-TestLowLatencyData1.o CCLD

Re: bug#8665: automake should offer APIs to honour silent-rules verbosity from shell code in Makefiles

Reviving and oldish bug report (and CC:ing the Automake list now). Reference: I wrote: > > A relevant excerpt [from the manual]: > > You can add your own variables, so strings of your own choice are shown. > The following snippet shows how you

Re: silent-rules

On Wed, 2009-10-14 at 03:17 +0200, Ralf Corsepius wrote: > > But YOU can still disable it by default, by writing your packaging > > automation tools to supply --disable-silent-rules as part of calling > > ./configure, and/or writing an appropriate config.site. In other wor

Re: silent-rules

On Thu, 15 Oct 2009, Ralf Corsepius wrote: "Look Ma, I can ride my bike with the hands off the handlebar" ... some hours later, the same kid will tell: "Look Ma, I can ride my bike without teeth". In other words, I am expecting the same users who find "AM_SILENT" "cool", to be loosing their

Re: silent-rules

NUstep packages, and we were badly bitten when there were incompatible changes (gnustep-make 1.x -> 2.x) a few years ago that were *hidden* by the silent output. So, what's the problem for you to pass --disable-silent-rules, --disable-shave, messages=yes, etc? I do it for all my packag

Re: silent-rules

On 10/14/2009 06:55 PM, Bob Friesenhahn wrote: On Wed, 14 Oct 2009, Ralf Wildenhues wrote: Actually, complaining can indeed change the situation. Exactly. To put it bluntly, I find the situation automake as shifted itself to be similar to this ole' joke: "Look Ma, I can ride my bike with t

Re: silent-rules

* Ralf Corsepius wrote on Wed, Oct 14, 2009 at 09:23:10AM CEST: > On 10/14/2009 07:05 AM, Ralf Wildenhues wrote: > > > >I still fail to understand. What problem do you have with either > > echo export V=1>> ~/.bashrc > > > >or > > echo enable_silent_rules=no>> ${CONFIG_SITE-/usr/local/share/

Re: silent-rules

ackages in batches. i.e. to monitor/inspect CFLAGS, CPPFLAGS, LDFLAGS etc. in compiler calls etc. for correctness (NB: A package, which compiles without warning doesn't mean it is being built correctly.) What work does it cause except for using --disable-silent-rules at configure time or V

Re: silent-rules

On Wed, 14 Oct 2009, Ralf Wildenhues wrote: What work does it cause except for using --disable-silent-rules at configure time or V=1 at make time? Exactly this is the problem. I still fail to understand. What problem do you have with either echo export V=1 >> ~/.bashrc or

Re: silent-rules

hes. > >> > >>i.e. to monitor/inspect CFLAGS, CPPFLAGS, LDFLAGS etc. in > >>compiler calls etc. for correctness > >> > >>(NB: A package, which compiles without warning doesn't mean it > >>is being built correctly.) > >> > &

Re: silent-rules

On 10/14/2009 02:58 AM, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Corsepius on 10/13/2009 9:20 AM: What work does it cause except for using --disable-silent-rules at configure time or V=1 at make time? Exactly this is the problem. The problem isn&#

Re: silent-rules

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Corsepius on 10/13/2009 9:20 AM: >>>> What work does it cause except for using --disable-silent-rules at >>>> configure time or V=1 at make time? >>> Exactly this is the problem. >> >> T

Re: silent-rules

h compiles without warning doesn't mean it is being built correctly.) What work does it cause except for using --disable-silent-rules at configure time or V=1 at make time? Exactly this is the problem. The problem isn't the support for silent rules. The problem is that some package

Re: silent-rules

is being built correctly.) What work does it cause except for using --disable-silent-rules at configure time or V=1 at make time? Exactly this is the problem. The problem isn't the support for silent rules. The problem is that some packages are enabling it by default because it looks like

Re: silent-rules

etc. for correctness (NB: A package, which compiles without warning doesn't mean it is being built correctly.) What work does it cause except for using --disable-silent-rules at configure time or V=1 at make time? Exactly this is the problem. It means automake is pushing around pack

silent-rules (was: checking automake version in configure.ac)

nuissance.) Could you expand on this nuisance a bit more? What work does it cause except for using --disable-silent-rules at configure time or V=1 at make time? This is an honest question; I'd like to avoid extra work for distributors. Thanks, Ralf

Re: makes which break with `silent-rules'

On Sat, 30 May 2009, Ralf Wildenhues wrote: POSIX says that; however different implementations of 'make' treat forward-references differently. Well that's when you would put XY_V last, just to be sure: XY_ = unknown XY_0 = silent XY_1 = verbose XY_V = $(XY_$(V)) then there is no forward ref

Re: makes which break with `silent-rules'

* Jan Engelhardt wrote on Wed, May 27, 2009 at 09:12:44PM CEST: > On Sunday 2009-05-24 15:24, Thomas Dickey wrote: > >> all : > >>echo $(XY_V) > >> > >> XY_V = $(XY_$(V)) > >> XY_0 = silent > >> XY_1 = verbose > >> XY_ = unknown > >> > >> I think this is supported by POSIX. POSIX [1] says: "Mac

Re: makes which break with `silent-rules'

On Sunday 2009-05-24 15:24, Thomas Dickey wrote: > On Sun, 24 May 2009, Bruno Haible wrote: > >>> - The `silent-rules' option enables Linux kernel-style silent build output. >>> This option requires the widely supported but non-POSIX `make' feature >

Re: makes which break with `silent-rules'

Hello Bruno, Bob, * Bruno Haible wrote on Sun, May 24, 2009 at 01:12:02PM CEST: > > - The `silent-rules' option enables Linux kernel-style silent build output. > >This option requires the widely supported but non-POSIX `make' feature > >of recursive var

Re: makes which break with `silent-rules'

On Sun, 24 May 2009, Bruno Haible wrote: - The `silent-rules' option enables Linux kernel-style silent build output. This option requires the widely supported but non-POSIX `make' feature of recursive variable expansion, We are talking about constructs like this: =

Re: makes which break with `silent-rules'

sorry, hit the send key too early. * Ralf Wildenhues wrote on Sun, May 24, 2009 at 03:20:04PM CEST: > IRIX make barfs if the inner macro expansion is used without $() or ${} > even for one-character macros. IOW, IRIX make barfs over $(foo$V) but > copes with $(foo$(V)). There are also some make

Re: makes which break with `silent-rules'

> - The `silent-rules' option enables Linux kernel-style silent build output. >This option requires the widely supported but non-POSIX `make' feature >of recursive variable expansion, We are talking about constructs like this: == Makefile == all :

Re: mailing list handling (was: My project can't use `silent-rules')

On Thu, 21 May 2009, Ralf Wildenhues wrote: It seems not easy to please you. :-) I am a PITA. :-) A while ago you (IMHO rightfully) complained about too much email coming your way, with duplicates due to cross-posting to more than one mailing list increasing the pressure even more. I can o

mailing list handling (was: My project can't use `silent-rules')

Hi Bob, all, * Bob Friesenhahn wrote on Sun, May 17, 2009 at 10:43:51PM CEST: > > P.S. I am pretty pissed that almost all recent discussion of automake > major features and direction has apparently taken place on the > automake-patches list rather than the automake list where it belongs. > N

Re: My project can't use `silent-rules'

permanently silence warnings from your code, you should probably just use appropriate pragmas or command-line options to disable those warnings. One of the primary reasons (IMHO) for Automake silent rules is so that I CAN see the warnings in my code (without resorting to redirecting make's stdo

Re: My project can't use `silent-rules'

On Mon, 18 May 2009, Ralf Wildenhues wrote: You can use AM_SILENT_RULES Worked! Thanks! Unfortunately, it does not silence the warnings from my code. I should open a new discussion thread on the autoconf list regarding the ability to obtain version and other package information from outsi

Re: My project can't use `silent-rules'

Hi Bob, * Bob Friesenhahn wrote on Sun, May 17, 2009 at 10:43:51PM CEST: > I see that the only way to request the new `silent-rules' feature is by > using the new form of AM_INIT_AUTOMAKE to pass the option. Since my > package can not use the new form of AM_INIT_AUTOMAKE, t

Re: makes which break with `silent-rules'

Hi Bob, * Bob Friesenhahn wrote on Sun, May 17, 2009 at 09:59:17PM CEST: > Is anyone aware of specific vendor make programs which fail with > automake 1.11's new `silent-rules' option? I don't know of any. Cheers, Ralf

Re: My project can't use `silent-rules'

On Sun, 17 May 2009, Bob Friesenhahn wrote: I still owe you large quantities of beer. However, in order to clarify, I would like to be able to execute configure script shell script code (more like a configure test) and not generate a new configure script just because the version has changed.

Re: My project can't use `silent-rules'

On Sun, 17 May 2009, Peter O'Gorman wrote: Hi Bob, You can use m4_easycmd to run your scripts at autoconf time. E.g. (from autoconf itself): AC_INIT([GNU Autoconf], m4_esyscmd([build-aux/git-version-gen .tarball-version]), [bug-autoc...@gnu.org]) I still owe you large quantities o

Re: My project can't use `silent-rules'

On Sun, 17 May 2009, NightStrike wrote: On Sun, May 17, 2009 at 4:43 PM, Bob Friesenhahn wrote: I see that the only way to request the new `silent-rules' feature is by using the new form of AM_INIT_AUTOMAKE to pass the option.  Since my package can not use the new form of AM_INIT_AUT

Re: My project can't use `silent-rules'

Bob Friesenhahn wrote: > It does not make sense to manually edit configure.ac each time a new > package needs to be produced. > > Is there a way that some of my own script code can be executed prior to > AC_INIT and a way to pass this information in a shell variable to > AC_INIT? If so, then I c

Re: My project can't use `silent-rules'

On Sun, May 17, 2009 at 4:43 PM, Bob Friesenhahn wrote: > I see that the only way to request the new `silent-rules' feature is by > using the new form of AM_INIT_AUTOMAKE to pass the option.  Since my package > can not use the new form of AM_INIT_AUTOMAKE, then it can not request &

Re: My project can't use `silent-rules'

On Sun, 2009-05-17 at 15:43 -0500, Bob Friesenhahn wrote: > The reason why my package can not use AC_INIT is that the package > version information is (often) computed by shell script code based on > the last entry in the project ChangeLog or other information. It is > (apparently) not possibl

Re: My project can't use `silent-rules'

Bob Friesenhahn writes: > The reason why my package can not use AC_INIT is that the package > version information is (often) computed by shell script code based on > the last entry in the project ChangeLog or other information. It is > (apparently) not possible for user-provided script code to b

My project can't use `silent-rules'

I see that the only way to request the new `silent-rules' feature is by using the new form of AM_INIT_AUTOMAKE to pass the option. Since my package can not use the new form of AM_INIT_AUTOMAKE, then it can not request `silent-rules'. The reason for this limitation is that using th

makes which break with `silent-rules'

Is anyone aware of specific vendor make programs which fail with automake 1.11's new `silent-rules' option? " - The `silent-rules' option enables Linux kernel-style silent build output. This option requires the widely supported but non-POSIX `make' feature

Re: choosing the default for silent-rules

Ralf Wildenhues wrote: > * Jim Meyering wrote on Sun, Apr 19, 2009 at 01:34:50PM CEST: >> Switching to silent-rules feels like progress, so I want it to be >> enabled by default, at least for packages I maintain. Of course, >> that's my judgment, and if enough p

Re: choosing the default for silent-rules

* Jim Meyering wrote on Sun, Apr 19, 2009 at 01:34:50PM CEST: > > Switching to silent-rules feels like progress, so I want it to be > enabled by default, at least for packages I maintain. Of course, > that's my judgment, and if enough people say that my enabling > silent-rule

Re: choosing the default for silent-rules

Ralf Wildenhues wrote: > * Jim Meyering wrote on Sun, Apr 19, 2009 at 10:53:40AM CEST: >> What if a package maintainer wants to enable >> automake's silent-rules option by default? > > Then you should argue for this; see the arguments against it here: ... Hi Ralf, I thi

Re: choosing the default for silent-rules

Hi Jim, * Jim Meyering wrote on Sun, Apr 19, 2009 at 10:53:40AM CEST: > What if a package maintainer wants to enable > automake's silent-rules option by default? Then you should argue for this; see the arguments against it here: <http://lists.gnu.org/archive/html/automake/2009-04

choosing the default for silent-rules

What if a package maintainer wants to enable automake's silent-rules option by default? Currently, even when I use AM_INIT_AUTOMAKE([silent-rules]) it's disabled, and to get the behavior I want, I have to run ./configure --enable-silent-rules or "make V=0". Is there a recomme

Re: [PATCH] build: use automake's --silent-rules option when possible

On Sun, 29 Mar 2009, Bob Friesenhahn wrote: On Sun, 29 Mar 2009, Thomas Dickey wrote: On Sun, 29 Mar 2009, Bob Friesenhahn wrote: By sufficiently noisy I mean that the user should be able to see the preprocessor and library search paths and any defines provided via the command line so they

Re: [PATCH] build: use automake's --silent-rules option when possible

On Sun, 29 Mar 2009, Thomas Dickey wrote: On Sun, 29 Mar 2009, Bob Friesenhahn wrote: By sufficiently noisy I mean that the user should be able to see the preprocessor and library search paths and any defines provided via the command line so they can be sure that the right bits are being used

Re: [PATCH] build: use automake's --silent-rules option when possible

On Sun, 29 Mar 2009, Jan Engelhardt wrote: Some projects' code outputs the flags at the end of configure, I think that's a nice overview, but actually, that's outside automake ;-) As for automake, this lil hack could do something similar # -*- Makefile -*- BUILT_SOURCES = show

Re: [PATCH] build: use automake's --silent-rules option when possible

On Sun, 29 Mar 2009, Bob Friesenhahn wrote: By sufficiently noisy I mean that the user should be able to see the preprocessor and library search paths and any defines provided via the command line so they can be sure that the right bits are being used. The config.status file provides this inf

Re: [PATCH] build: use automake's --silent-rules option when possible

On Sunday 2009-03-29 17:43, Bob Friesenhahn wrote: > > We can suggest using "make V=1" but end users are most likely to execute > './configure', 'make', 'make install' without reading most of the package > install documentation. >[...] > By sufficiently noisy I mean that the user should be able to

Re: [PATCH] build: use automake's --silent-rules option when possible

On Sun, 29 Mar 2009, Ralf Corsepius wrote: CC id.o Now your users won't see the "silent bugs" your package comes with. I am seriously asking: Why are you doing this? To me, such "silence" means cheating at one selves about the quality of a package and "playing down" the bugs a package is s

Re: [PATCH] build: use automake's --silent-rules option when possible

On Sun, 29 Mar 2009, Jim Meyering wrote: Thomas Dickey wrote: well (recalling previous discussion), the reason that Ralf's complaining is that while it makes working on your program simpler it makes finding bugs in _automake_ harder. If you think seeing those long gcc command lines in a *core

Re: [PATCH] build: use automake's --silent-rules option when possible

Thomas Dickey wrote: > On Sun, 29 Mar 2009, Jim Meyering wrote: >> Ralf Corsepius wrote: >>> Jim Meyering wrote: >>>> I like automake's upcoming --silent-rules option enough >>>> that I'm making it the default (when possible) for coreutils.

Re: [PATCH] build: use automake's --silent-rules option when possible

On Sun, 29 Mar 2009, Jim Meyering wrote: Ralf Corsepius wrote: Jim Meyering wrote: I like automake's upcoming --silent-rules option enough that I'm making it the default (when possible) for coreutils. Well, if you think such a step to be helpful, I disagree. Then you can build

Re: [PATCH] build: use automake's --silent-rules option when possible

Ralf Corsepius wrote: > Jim Meyering wrote: >> I like automake's upcoming --silent-rules option enough >> that I'm making it the default (when possible) for coreutils. > Well, if you think such a step to be helpful, I disagree. Then you can build with "make

Re: [PATCH] build: use automake's --silent-rules option when possible

Ralf Corsepius writes: > Jim Meyering wrote: >> Since I bootstrap using automake from its "next" branch, it's >> enabled for me. And that translates to enhanced Makefile.in >> files in the tarballs I generate. The net result is that when >> you run "make" (using distributed Makefile.in files),

Re: [PATCH] build: use automake's --silent-rules option when possible

Jim Meyering wrote: I like automake's upcoming --silent-rules option enough that I'm making it the default (when possible) for coreutils. Well, if you think such a step to be helpful, I disagree. Since I bootstrap using automake from its "next" branch, it's

Re: [PATCH] build: use automake's --silent-rules option when possible

El Sábado 28 Marzo 2009ES 17:14:10 Jan Engelhardt escribió: > On Saturday 2009-03-28 16:44, Ralf Wildenhues wrote: > >Hi Bob, Jim, > > > >* Bob Friesenhahn wrote on Sat, Mar 28, 2009 at 04:40:16PM CET: > >> On Sat, 28 Mar 2009, Jim Meyering wrote: > >>>

Re: [PATCH] build: use automake's --silent-rules option when possible

On Saturday 2009-03-28 16:44, Ralf Wildenhues wrote: >Hi Bob, Jim, > >* Bob Friesenhahn wrote on Sat, Mar 28, 2009 at 04:40:16PM CET: >> On Sat, 28 Mar 2009, Jim Meyering wrote: >> >>> I like automake's upcoming --silent-rules option enough >>> that I

Re: [PATCH] build: use automake's --silent-rules option when possible

Hi Bob, Jim, * Bob Friesenhahn wrote on Sat, Mar 28, 2009 at 04:40:16PM CET: > On Sat, 28 Mar 2009, Jim Meyering wrote: > >> I like automake's upcoming --silent-rules option enough >> that I'm making it the default (when possible) for coreutils. [...] >> CC id

Re: [PATCH] build: use automake's --silent-rules option when possible

On Sat, 28 Mar 2009, Jim Meyering wrote: I like automake's upcoming --silent-rules option enough that I'm making it the default (when possible) for coreutils. Since I bootstrap using automake from its "next" branch, it's enabled for me. And that translates to enhanced

[PATCH] build: use automake's --silent-rules option when possible

I like automake's upcoming --silent-rules option enough that I'm making it the default (when possible) for coreutils. Since I bootstrap using automake from its "next" branch, it's enabled for me. And that translates to enhanced Makefile.in files in the tarballs I generate