Re: make automake less verbose (try 2)

[Jan Engelhardt]

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_*.