On Thursday 2008-10-23 19:20, Ralf Wildenhues wrote: > >Anyway, when we use nonconforming constructs then it's probably safer if >they are default-off, so the developer can choose to enable it and knows >the limitation. I suppose we can have an Automake option 'silent' or so >(better name suggestions appreciated), or maybe additionally a command >line argument if there is much desire for that.
Probably so. Then I would like to see a macro for use in configure.ac that toggles the default behavior. Something like AM_SILENT_BY_DEFAULT (and the converse,) AM_VERBOSE_BY_DEFAULT where AM_VERBOSE_BY_DEFAULT is, eh, the default, when omitted. When AM_VERBOSE_BY_DEFAULT is in effect, we can just add a V=1 to the Makefile, and users can override it with `make V=` to quieten it. Sounds like a plan. And soon, the next idea crops up :-/ a `make Q=` mnemonic that is the opposite of V. I guess that will open a can of syntax worms, and requires like __AM_VERBOSE_CC.1 = echo... # V=1 __AM_VERBOSE_CC0.1 = echo... # V=1 Q=0 __AM_VERBOSE_CC1. = echo... # Q=1 __AM_VERBOSE_CC1.1 = echo... # AM_VERBOSE_CC = ${__AM_VERBOSE_CC${Q}.${V}} etc. >A few more nits below. FWIW, if you are willing to work on this more, >that would be great. If you aren't, then no problem, I (or somebody >else) will get to it eventually. (If you won't sign papers, then it's >in fact easier for us to fix things if you don't submit patches.) Let's see.. >Can you please state how and on what systems/packages/compilers etc. you >tested the patch, and whether you ran Automake's testsuite? Thanks! Since this is automake related, I was totally ignorant about compiler ;-) Packages? Quite a few. Every RPM in my build root whose specfile issued autoreconf/automake. I don't feel like counting them, but of course, it is only a fraction of all RPMs produced, simply because rebuilding the Makefile.ins does take its time, and it quickly accumulates. Ever since I wrote the initial patch last year, all those packages were under the testing of the modified automake. The patch I posted today has not had exposure beyond libHX and pam_mount yet, but this year's patch only had minimal changes from last year's try. Essentially, only the AM_VERBOSE variables in the biggest hunk were touched. I mean I knew the only thing that stopped me from world dom^W^W^W was the $(ifeq) line. I would rather hit a Perl syntax error before getting a problem with the Makefile automake would produce ;-) — at least within the tested systems. Systems tested: GNU make 3.81, Solaris 10 make, OpenBSD 4.3's make. For fun I tried it on some packages: hte (hte.sf.net) and pidgin. > >FWIW, the patch needs a test or two, documentation, a NEWS and a >ChangeLog entry. > >> --- automake-1.10.1.orig/automake.in >> +++ automake-1.10.1/automake.in > >> + 'verbose_link' => '${AM_VERBOSE_CXXLD}', > >(wondering whether to use am__verbose_CCXLD and likewise here) Most likely so. >How come you use ${...} everywhere, instead of $(...) as is done in the >rest of Automake? See HACKING for some conventions, that, stupid as >they may be, at least bring a bit of consistency. Using ${} — for consistency, as strange as that sounds: Shell uses ${foo} (besides $foo, yes yes). Perl uses ${foo}. So does PHP. And none of them use $() for variables. So there must have been a mad scientist who stepped out of line and added $() to make in the 70s(?) or so. >I wonder whether verbose_compile and verbose_link can be autogenerated >resp. mapped from compiler and lder, respectively. Hmm. > >> @@ -2410,6 +2442,15 @@ sub handle_libtool >> LTRMS => join ("\n", @libtool_rms)); >> } >> >> +sub find_link_verbose($) >> +{ >> + foreach my $lang_name (keys %languages) { >> + if ($languages{$lang_name}->linker eq $_[0]) { >> + return $languages{$lang_name}->verbose_link; >> + } >> + } >> +} > >That's a bit inefficient, looping over all languages each time. >Can't you do something like this? > > if (exists $languages{$lang_name}) > { > return $languages{$lang_name}->verbose_link; > } > return undef; I did this because there seem to be multiple languages with the same ->linker but with different ->verbose_link -- something like that, I really get lost in the automake source. It had to do with CXXLD overriding CCLD in a program which consists of both flavors, i.e. bin_PROGRAMS = foo foo_SOURCES = a.c b.cpp >> @@ -2761,7 +2806,9 @@ sub handle_ltlibraries >> NONLIBTOOL => 0, LIBTOOL => 1); >> >> # Determine program to use for link. >> - my $xlink = &define_per_target_linker_variable ($linker, $xlib); >> + my($xlink, $vlink) = &define_per_target_linker_variable ($linker, >> $xlib); >> + $vlink ||= &find_link_verbose($xlink); >> + $vlink ||= ""; >> >> my $rpathvar = "am_${xlib}_rpath"; >> my $rpath = "\$($rpathvar)"; > > >> + # We are using an indirection via __AM_VERBOSE_* here so that >> + # ${V} is not used in any files but automake.in itself, >> + # especially avoiding the use of ${V} template files. >> + # >> + # GEN is for generate, which you can use for any manual rules. >> + $output_vars .= join("\n", >> + '__AM_LIBTOOL_SILENT = --silent', > >Variables with leading underscores are not universally portable; the >naming convention in HACKING recommends am__ as prefix. yup. let's do that. >I think this code piece should use one of the define_*variable >functions, for nicely formatted output, and variables that are not used >in the Makefile.in should not need to be defined, to avoid bloat. Right. But I would like to keep AM_VERBOSE_GEN, to be able to have some sort of silent output for non-automake programs, e.g.: foo.out: foo.in ${AM_VERBOSE_GEN}perl $< >$@ >> + '__AM_VERBOSE_CC = @echo " CC " $@;', > >Honest question: why the leading white space in the output? >All it does is take away screen space, no? Or is the goal >bit-for-bit compatibility with Linux output? bit-for-bit compatibility. I wanted the exact Linux output. No square brackets or other funstuff people added to their version of silence-automake patches. As I think about it, the leading indent actually helps readability - IMO - since both make's "entering subdirectory" as well as compile warnings/errors begin in the first column. That's probably also the reason why this was done so in kbuild. >[...] >> + 'AM_LIBTOOL_SILENT = ${__AM_LIBTOOL_SILENT${V}}', > > >> --- automake-1.10.1.orig/lib/am/depend2.am >> +++ automake-1.10.1/lib/am/depend2.am >> @@ -63,6 +63,7 @@ if %?NONLIBTOOL% >> ?GENERIC?%EXT%.o: >> ?!GENERIC?%OBJ%: %SOURCE% >> if %FASTDEP% >> + %VERBOSE% \ > >For a default-off automake-time decision, the .am snippets changes would >need a ?SILENT? or so modifier (can also use ternary operators for bits >with finer than line granularity). See above; I think default-off/default-on behavior can simply be toggled (and should be togglable) using a configure-time @VARIABLE@ instead of an automake-specific %VARIABLE%. >I'm not all that happy about the extra line of output in the V=1 case >here. Probably better if the %VERBOSE% happens on the same line as the >compile command, even if that unfortunately means more duplication >inside depend2.am; like I noticed. It's a byproduct that I happen to like. Even with V=1 you get a blank line for, ahem, what people tout as readability :) That way, the compile line(s) and any errors caused by it are agglomerated together in a blob block on-screen. >?!GENERIC? %SILENT?%VERBOSE% :%%COMPILE% -MT ... > >Ah, there may be an even better alternative. At least for the gcc3 >fastdep path, we can just use another command line, with @ prefixed. >Since there > >> ## In fast-dep mode, we can always use -o. >> ## For non-suffix rules, we must emulate a VPATH search on %SOURCE%. >> ?!GENERIC? %COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo %-c% -o %OBJ% >> `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE% && \ >> @@ -71,6 +72,7 @@ if %FASTDEP% >> ?GENERIC??SUBDIROBJ? %COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo >> %-c% -o %OBJ% %SOURCE% &&\ >> mv -f %DEPBASE%.Tpo %DEPBASE%.Po > >How come you didn't address the mv calls? Should be possible with >something like > am__at = @ > AM__AT = $(am__at$(V)) > > $(AM__AT)mv -f %DEPBASE%.Tpo %DEPBASE%.Po I did not want to overdo it. Non-compile lines are rare in my projects, and I guess you could call me lazy here. Feel free to add a AM_VERBOSE_MV and AM_VERBOSE_RM if you feel like. Users will probably like it because it goes in line with the compile-quietness of AM_VERBOSE_CC. Since you quoted am__at, I think that is what should also be used instead of the literal @ in AM_VERBOSE_*.