Re: [PATCH 4/4] New automake command line option `--silent-rules'.
* Jan Engelhardt wrote on Wed, Mar 11, 2009 at 10:55:02PM CET:
On Wednesday 2009-03-11 22:43, Ralf Wildenhues wrote:
The command line option --silent-rules does the same as the argument
`silent' to the AM_INIT_AUTOMAKE macro in configure.ac:
AM_INIT_AUTOMAKE([silent])
Both enable silent mode for all Makefile.in files.
Hm that's a bit unintuitive. One can run `automake -Wall` from the
command line, and one can put -Wall into AM_INIT_AUTOMAKE().
One can use --foreign as a CLI argument, and AUTOMAKE_OPTIONS=foreign
(and probably AM_INIT_AUTOMAKE([foreign])).
But introducing two names for silent/silent-rules, well.. ick.
Agreed.
The reason that the command line option is not called `--silent' is that
normally, i.e., with several other GNU software, --silent is the
opposite of --verbose, and changes the verbosity of the command. But
--silent-rules does not change the verbosity of the automake command.
Yeah I thought so. In that case, I would avoid using silent at all
and consistently use silent-rules throughout.
Good idea. Pushed.
Thanks,
Ralf
Rename `silent' mode to `silent-rules' mode.
* automake.in (define_verbose_var, verbose_flag)
(define_verbose_tagvar, handle_options, handle_languages)
(handle_configure, parse_arguments): Rename the `silent' option
to `silent-rules', so it coincides with the `--silent-rules'
command line option; adjust all code and comments.
* lib/Automake/Options.pm (_process_option_list): Likewise.
* doc/automake.texi (Invoking Automake, Libtool Flags, Options):
Likewise.
* NEWS: Adjust.
* tests/dollarvar.test, tests/silent.test, tests/silent2.test,
tests/silent3.test, tests/silent4.test, tests/silent5.test,
tests/silent6.test, tests/silent7.test: Likewise.
Suggestion by Jan Engelhardt.
diff --git a/NEWS b/NEWS
index 6975751..885abc0 100644
--- a/NEWS
+++ b/NEWS
@@ -109,7 +109,7 @@ New in 1.10a:
- The `color-tests' option causes colored test result output on terminals.
- - The `silent' option enables Linux kernel-style silent build output.
+ - 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, so do not use it if your package needs
to build with `make' implementations that do not support it.
diff --git a/automake.in b/automake.in
index 9ee9dfd..cb4d1de 100755
--- a/automake.in
+++ b/automake.in
@@ -,11 +,11 @@ sub backname ($)
-# Silent mode handling functions.
+# `silent-rules' mode handling functions.
# verbose_var (NAME)
# --
-# The public variable stem used to implement `silent'.
+# The public variable stem used to implement `silent-rules'.
sub verbose_var ($)
{
my ($name) = @_;
@@ -1124,7 +1124,7 @@ sub verbose_var ($)
# verbose_private_var (NAME)
# --
-# The naming policy for the private variables used to implement `silent'.
+# The naming policy for the private variables for `silent-rules'.
sub verbose_private_var ($)
{
my ($name) = @_;
@@ -1133,13 +1133,13 @@ sub verbose_private_var ($)
# define_verbose_var (NAME, VAL)
# --
-# For `silent' mode, setup VAR and dispatcher, to expand to VAL if silent.
+# For `silent-rules' mode, setup VAR and dispatcher, to expand to VAL if
silent.
sub define_verbose_var ($$)
{
my ($name, $val) = @_;
my $var = verbose_var ($name);
my $pvar = verbose_private_var ($name);
-if (option 'silent')
+if (option 'silent-rules')
{
# Using `$V' instead of `$(V)' breaks IRIX make.
define_variable ($var, '$(' . $pvar . '_$(V))', INTERNAL);
@@ -1157,7 +1157,7 @@ sub verbose_flag ($)
{
my ($name) = @_;
return '$(' . verbose_var ($name) . ')'
- if (option 'silent');
+ if (option 'silent-rules');
return '';
}
@@ -1171,11 +1171,11 @@ sub silent_flag ()
# define_verbose_tagvar (NAME)
#
-# Engage the needed `silent' machinery for tag NAME.
+# Engage the needed `silent-rules' machinery for tag NAME.
sub define_verbose_tagvar ($)
{
my ($name) = @_;
-if (option 'silent')
+if (option 'silent-rules')
{
define_verbose_var ($name, '@echo '. $name . ' ' x (6 - length
($name)) . ' $@;');
define_verbose_var ('at', '@');
@@ -1184,7 +1184,7 @@ sub define_verbose_tagvar ($)
# define_verbose_libtool
# --
-# Engage the needed `silent' machinery for `libtool --silent'.
+# Engage the needed `silent-rules' machinery for `libtool --silent'.
sub define_verbose_libtool ()
{
define_verbose_var ('lt', '--silent');
@@ -1216,7 +1216,7 @@ sub handle_options
# Override portability-recursive warning.
switch_warning ('no-portability-recursive')
-if option 'silent';
+if option
Re: [PATCH 4/4] New automake command line option `--silent-rules'.
* Ralf Wildenhues wrote on Sun, Mar 08, 2009 at 10:46:40AM CET:
The current patch still has a couple of warts in that --silent-rules
should turn off portability-recursive warnings independently of the
command line argument order. This is another reason I don't like this
addition much: it needs more special-casing and complex semantics in
order to work seamlessly for users.
Second bug fix of this patch. Pushed to the branch.
The ugliness of the implementation has been mostly fixed now. So it's
more or less a matter of:
Do we want to allow a command line knob (--silent-rules) to turn
off `silent' mode, or do we force developers to either touch the
AUTOMAKE_OPTIONS variable in Makefile.am or the AM_INIT_AUTOMAKE
macro call in configure.ac?
List feedback has been mixed so far; there are good arguments on both
sides.
The --$flavor (cygwin|foreign|gnu|gnits) and --ignore-deps precedents
tend to make me say yes on this matter, leaning ever so slightly over
the edge.
Thanks,
Ralf
`silent' mode unconditionally overrides portability-recursive.
* automake.in (parse_arguments): Don't handle a global `silent'
option here; instead, ...
(handle_options): ... handle the normal `silent' option here.
Override `portability-recursive' here, at the last point we deal
with options, instead ...
* lib/Automake/Options.pm (_process_option_list): ... of here.
* tests/silent6.test: Replace unportable make snippet, remove
FIXME note, add more test cases of options passed in the various
locations.
diff --git a/automake.in b/automake.in
index fac2313..9ee9dfd 100755
--- a/automake.in
+++ b/automake.in
@@ -1214,6 +1214,10 @@ sub handle_options
}
}
+ # Override portability-recursive warning.
+ switch_warning ('no-portability-recursive')
+if option 'silent';
+
if ($strictness == GNITS)
{
set_option ('readme-alpha', INTERNAL);
@@ -8189,10 +8193,6 @@ sub parse_arguments ()
$output_directory = '.';
}
- # Override portability-recursive warning.
- process_global_option_list ($cli_where, 'silent')
-if global_option 'silent';
-
return unless @ARGV;
if ($ARGV[0] =~ /^-./)
diff --git a/lib/Automake/Options.pm b/lib/Automake/Options.pm
index 3c152df..10fd00f 100644
--- a/lib/Automake/Options.pm
+++ b/lib/Automake/Options.pm
@@ -267,6 +267,7 @@ sub _process_option_list (\%$@)
|| $_ eq 'no-exeext' || $_ eq 'no-define'
|| $_ eq 'std-options'
|| $_ eq 'color-tests'
+|| $_ eq 'silent'
|| $_ eq 'cygnus' || $_ eq 'no-dependencies')
{
# Explicitly recognize these.
@@ -310,10 +311,6 @@ sub _process_option_list (\%$@)
if switch_warning $cat;
}
}
- elsif ($_ eq 'silent')
-{
- switch_warning ('no-portability-recursive');
- }
else
{
error ($where, option `$_' not recognized,
diff --git a/tests/silent6.test b/tests/silent6.test
index 2bc2f8f..103cd34 100755
--- a/tests/silent6.test
+++ b/tests/silent6.test
@@ -30,7 +30,7 @@ EOF
cat Makefile.am 'EOF'
if SILENT
-my_verbose = $(my_verbose_$V)
+my_verbose = $(my_verbose_$(V))
my_verbose_ = $(my_verbose_0)
my_verbose_0 = @echo GEN $@;
endif
@@ -46,8 +46,7 @@ EOF
: foo.in
$ACLOCAL
-# FIXME: it should not be necessary to disable Wportability here.
-$AUTOMAKE --add-missing -Wno-portability --silent-rules
+$AUTOMAKE --add-missing --silent-rules
$AUTOCONF
./configure silent_rules=yes
@@ -70,4 +69,30 @@ cat stdout
grep 'GEN foo' stdout Exit 1
grep 'cp ' stdout
+$MAKE distclean
+
+# Things should also work with -Wall in AM_INIT_AUTOMAKE.
+cat configure.in 'END'
+AC_INIT([silent6], [1.0])
+AM_INIT_AUTOMAKE([-Wall])
+AM_CONDITIONAL([SILENT], [:])
+AC_CONFIG_FILES([Makefile])
+AC_OUTPUT
+END
+
+$ACLOCAL
+AUTOMAKE_fails --force
+$AUTOMAKE --force -Wno-error
+grep ' --silent-rules' Makefile.in Exit 1
+$AUTOMAKE --force --silent-rules
+grep ' --silent-rules' Makefile.in
+$AUTOMAKE --force -Wno-all -Wportability --silent-rules
+grep ' --silent-rules' Makefile.in
+
+echo 'AUTOMAKE_OPTIONS = silent' Makefile.am
+$AUTOMAKE --force
+grep 'AM_V_GEN' Makefile.in
+$AUTOMAKE --force -Wno-all -Wportability
+grep 'AM_V_GEN' Makefile.in
+
:
Re: [PATCH 4/4] New automake command line option `--silent-rules'.
On Wednesday 2009-03-11 21:06, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Sun, Mar 08, 2009 at 10:46:40AM CET: The current patch still has a couple of warts in that --silent-rules should turn off portability-recursive warnings independently of the command line argument order. This is another reason I don't like this addition much: it needs more special-casing and complex semantics in order to work seamlessly for users. Second bug fix of this patch. Pushed to the branch. The ugliness of the implementation has been mostly fixed now. So it's more or less a matter of: Do we want to allow a command line knob (--silent-rules) to turn off `silent' mode, or do we force developers to either touch the AUTOMAKE_OPTIONS variable in Makefile.am or the AM_INIT_AUTOMAKE macro call in configure.ac? Hm, what is the difference between silent and silent-rules?
Re: [PATCH 4/4] New automake command line option `--silent-rules'.
* Jan Engelhardt wrote on Wed, Mar 11, 2009 at 09:34:20PM CET: On Wednesday 2009-03-11 21:06, Ralf Wildenhues wrote: Do we want to allow a command line knob (--silent-rules) to turn off `silent' mode, or do we force developers to either touch the AUTOMAKE_OPTIONS variable in Makefile.am or the AM_INIT_AUTOMAKE macro call in configure.ac? Hm, what is the difference between silent and silent-rules? The command line option --silent-rules does the same as the argument `silent' to the AM_INIT_AUTOMAKE macro in configure.ac: AM_INIT_AUTOMAKE([silent]) Both enable silent mode for all Makefile.in files. Per-Makefile.in silent mode may be enabled by adding AUTOMAKE_OPTIONS = silent to the respective Makefile.am. The reason that the command line option is not called `--silent' is that normally, i.e., with several other GNU software, --silent is the opposite of --verbose, and changes the verbosity of the command. But --silent-rules does not change the verbosity of the automake command. Hope that clears things up. Cheers, Ralf
Re: [PATCH 4/4] New automake command line option `--silent-rules'.
On Wednesday 2009-03-11 22:43, Ralf Wildenhues wrote: * Jan Engelhardt wrote on Wed, Mar 11, 2009 at 09:34:20PM CET: On Wednesday 2009-03-11 21:06, Ralf Wildenhues wrote: Do we want to allow a command line knob (--silent-rules) to turn off `silent' mode, or do we force developers to either touch the AUTOMAKE_OPTIONS variable in Makefile.am or the AM_INIT_AUTOMAKE macro call in configure.ac? Hm, what is the difference between silent and silent-rules? The command line option --silent-rules does the same as the argument `silent' to the AM_INIT_AUTOMAKE macro in configure.ac: AM_INIT_AUTOMAKE([silent]) Both enable silent mode for all Makefile.in files. Hm that's a bit unintuitive. One can run `automake -Wall` from the command line, and one can put -Wall into AM_INIT_AUTOMAKE(). One can use --foreign as a CLI argument, and AUTOMAKE_OPTIONS=foreign (and probably AM_INIT_AUTOMAKE([foreign])). But introducing two names for silent/silent-rules, well.. ick. The reason that the command line option is not called `--silent' is that normally, i.e., with several other GNU software, --silent is the opposite of --verbose, and changes the verbosity of the command. But --silent-rules does not change the verbosity of the automake command. Yeah I thought so. In that case, I would avoid using silent at all and consistently use silent-rules throughout.
Re: [PATCH 4/4] New automake command line option `--silent-rules'.
Ralf Wildenhues wrote: * Ralf Corsepius wrote on Mon, Mar 09, 2009 at 03:57:58PM CET: Jan Engelhardt wrote: On Monday 2009-03-09 15:44, Ralf Corsepius wrote: Ralf Wildenhues wrote: For this patch, I'm unsure if we should even add it at all. FWIW: I am opposed to it. I suppose you are opposed to the whole topic, rather than only to patch number 4? All this silencing stuff does is to add further potential sources of errors. Certainly. All new code does this, to some degree. Right .. and the autotools have an infamous record of doing so. The patches in the branch should not modify automake's output much if the `silent' option is not used. %VERBOSE% Of course there can still be regressions due to necesarily changed code inside automake (see patch 1 for a minor known example that I'll fix before merging the branch). My particular question above was meant as: I am unsure whether the fourth patch in the series is worth applying. I haven't checked all details of the patches, because I consider this whole endeavor (adding --silent) to be adding nothing but useless bloat to cater some people's demands, who are not able to understand the harm silencing does. I do consider the series worth applying, and I will use patches 1-3 plus fixes unless we find a very serious issue with it. Well, I disagree - Once it's in you will not be able to get rid of it for at least the next decade. My current take on patch 4 is this: It has the chance of making silent rebuilds easy for distributors, Depends on whom you are referring to as distributors Upstream maintainers (people who distribute tarballs) are interested seeing verbose logs, to be able to go after issues their users have. Silencing will force them to tell their users to please disable silencing, your logs don't contain sufficient information. OS vendors/distributors are interested in seeing verbose logs, because they typically are running build jobs in batches and therefore have a need to analyze their batches' logs (not only in case of breakdowns, but also to verify correct operation). [FWIW: In Fedora, we explicitly mandate verbose cmake logs for this purpose. One side-effect of cmake using a silent default: many packages suffer from silent bugs.] Developers are interested in seeing verbose logs, because they want to see their bugs, not only fatal ones but also silent ones (e.g. compilers receiving duplicate/bogus CPPFLAGS) There is only one group who is interested in real silence: Occasional random users, who are not able to understand/parse the verbosity. Ralf, wishing people would spend as much time writing tests as they would discussing Well, silencing to me is such kind of absurd, I am not interested in testing this. Ralf
Re: [PATCH 4/4] New automake command line option `--silent-rules'.
Ralf Wildenhues wrote: For this patch, I'm unsure if we should even add it at all. It adds an automake option to enable silent build rules. Here's why I wrote it in the first place: if you are a distribution and want to change all your packages to build silently, you may not want to change each package's configure.ac file. So instead you could change $AUTOMAKE to contain this flag. Do you think this is worthwhile to even have? If not, I will probably want to leave it out for 1.11. Hi Ralf! Yes, this is a very worthwhile patch, adding a feature I have wanted for a long time. You have my hearty Yes! vote ;-)
Re: [PATCH 4/4] New automake command line option `--silent-rules'.
Jan Engelhardt wrote: On Monday 2009-03-09 15:44, Ralf Corsepius wrote: Ralf Wildenhues wrote: For this patch, I'm unsure if we should even add it at all. FWIW: I am opposed to it. All this silencing stuff does is to add further potential sources of errors. Which ones, please? Those yet to be discovered.
Re: [PATCH 4/4] New automake command line option `--silent-rules'.
On Monday 2009-03-09 15:57, Ralf Corsepius wrote: For this patch, I'm unsure if we should even add it at all. FWIW: I am opposed to it. All this silencing stuff does is to add further potential sources of errors. Which ones, please? Those yet to be discovered. Oh what great prejudice. Do you actually know what exactly this patch series silences, or are you just guessing?
Re: [PATCH 4/4] New automake command line option `--silent-rules'.
Jan Engelhardt wrote: On Monday 2009-03-09 15:57, Ralf Corsepius wrote: For this patch, I'm unsure if we should even add it at all. FWIW: I am opposed to it. All this silencing stuff does is to add further potential sources of errors. Which ones, please? Those yet to be discovered. Oh what great prejudice. No, that's experience and a matter of design. IMNSHO, this --silent thing is entirely superfluous featuritis, whose only achievement it is to stir up things.
Re: [PATCH 4/4] New automake command line option `--silent-rules'.
On Monday 2009-03-09 16:10, Ralf Corsepius wrote: For this patch, I'm unsure if we should even add it at all. FWIW: I am opposed to it. All this silencing stuff does is to add further potential sources of errors. Which ones, please? Those yet to be discovered. Oh what great prejudice. No, that's experience and a matter of design. IMNSHO, this --silent thing is entirely superfluous featuritis, whose only achievement it is to stir up things. And I take it you also oppose cmake then - just out of principle -, which has some similar silent mode too (by default even!)... What is being quiesced (it's not even silent, linguistically) is the utterly long command line that is traditionally so prevalent during compilation in automake-using projects. Not the warnings or errors $CC would give, so I find your claim without substance.
Re: [PATCH 4/4] New automake command line option `--silent-rules'.
Jan Engelhardt wrote: On Monday 2009-03-09 16:10, Ralf Corsepius wrote: For this patch, I'm unsure if we should even add it at all. FWIW: I am opposed to it. All this silencing stuff does is to add further potential sources of errors. Which ones, please? Those yet to be discovered. Oh what great prejudice. No, that's experience and a matter of design. IMNSHO, this --silent thing is entirely superfluous featuritis, whose only achievement it is to stir up things. And I take it you also oppose cmake then Correct. - just out of principle -, No, ... but my reasons for not liking cmake are off-topic here. which has some similar silent mode too (by default even!)... Correct. that's one of cmake's sillynesses. It hides away the silent bugs a package suffers from. What is being quiesced (it's not even silent, linguistically) is the utterly long command line that is traditionally so prevalent during compilation in automake-using projects. Not the warnings or errors $CC would give, so I find your claim without substance. Pardon, but you are fixing something, which has hardly been an issue (I recall you repeatedly complaining about it), for the 15years+, the autotools are around. Ralf
Re: [PATCH 4/4] New automake command line option `--silent-rules'.
On Monday 2009-03-09 16:54, Ralf Corsepius wrote: which has some similar silent mode too (by default even!)... Correct. that's one of cmake's sillynesses. It hides away the silent bugs a package suffers from. Potential bugs in the command line invoking $CC that automake generates just go as unnoticed in all the jabber it outputs. What is being quiesced (it's not even silent, linguistically) is the utterly long command line that is traditionally so prevalent during compilation in automake-using projects. Not the warnings or errors $CC would give, so I find your claim without substance. Pardon, but you are fixing something, which has hardly been an issue (I recall you repeatedly complaining about it), for the 15years+, the autotools are around. Well I am *so* sorry that I did not propose this feature to autotools when it was first created by rms - the Internet boom came like 8 years later only. BTW it is not a bugfix, it is a feature. And I am not complaining about 'it', but making my remark (as have others), which, as it stands, happens to be in stark contrast to your position (who would have guessed). It's not like --silent was forced upon you.
Re: [PATCH 4/4] New automake command line option `--silent-rules'.
* Ralf Corsepius wrote on Mon, Mar 09, 2009 at 03:57:58PM CET: Jan Engelhardt wrote: On Monday 2009-03-09 15:44, Ralf Corsepius wrote: Ralf Wildenhues wrote: For this patch, I'm unsure if we should even add it at all. FWIW: I am opposed to it. I suppose you are opposed to the whole topic, rather than only to patch number 4? All this silencing stuff does is to add further potential sources of errors. Certainly. All new code does this, to some degree. The patches in the branch should not modify automake's output much if the `silent' option is not used. Of course there can still be regressions due to necesarily changed code inside automake (see patch 1 for a minor known example that I'll fix before merging the branch). My particular question above was meant as: I am unsure whether the fourth patch in the series is worth applying. I do consider the series worth applying, and I will use patches 1-3 plus fixes unless we find a very serious issue with it. My current take on patch 4 is this: It has the chance of making silent rebuilds easy for distributors, but OTOH is has the potential downside of taking the decision away from the package maintainer. I definitely want the package maintainer to be able to say: I do not want to see bug reports that lack compile command lines; thus I do not enable the `silent' feature. Aside, patch 4 also has rebuild issues ATM (the --silent-rules arg is not stored in the rebuild rule). So, I'm considering reverting patch 4. Cheers, Ralf, wishing people would spend as much time writing tests as they would discussing
Re: [PATCH 4/4] New automake command line option `--silent-rules'.
Hi, Jan Engelhardt jeng...@medozas.de writes: On Monday 2009-03-09 15:57, Ralf Corsepius wrote: For this patch, I'm unsure if we should even add it at all. FWIW: I am opposed to it. All this silencing stuff does is to add further potential sources of errors. Which ones, please? Those yet to be discovered. Oh what great prejudice. Do you actually know what exactly this patch series silences, or are you just guessing? If I understand the context, Ralf is objecting to the --silent-rules command-line option which makes it easy for distribution vendors to enable silent builds across the board by overriding $AUTOMAKE. I agree with the sentiment (somewhat hinted-to by Ralf Wildenhues in his commit message): this feature should be an opt-in by the package maintainer. He should take the responsibility for making the trade-off: easier-to-read silent builds vs. potential bugs due to hiding of information. - Hari
