Re: automake less verbose (iter 3.1)

[Jan Engelhardt]

On Monday 2008-12-15 21:19, William Pursell wrote:
>
>Thanks for this Jan, it is really nice functionality.  I don't
>know if this is a portability issue, but I think it would be nice
>to change $< to $? in this section:
>
>> +            'am__1verbose_CCLD_1   = @echo "  CCLD    " $@ "<-" $<;',
>> +            'am__1verbose_CXX_1    = @echo "  CXX     " $@ "<-" $<;',
>> +            'am__1verbose_CXXLD_1  = @echo "  CXXLD   " $@ "<-" $<;',

The intention of using $< was that only one file was shown on the
right side of the arrow, because all the other files in $^, including
header files, and I certainly don't need nor want that displayed as
it is a huge list.

The make info pages mention that $? expands to “all the prerequisites
that are newer than the target”, and that sounds like there could be
more than just the .c file.

I just noticed that LD should have used $^.

>In the case with lots of dependencies, that might lead to excess
>verbage, but that's what V=0 is for, right?  Or maybe use $? in a
>V=2 case.  Also, for those who like customizability, it might
>be nice to allow the maintainer to specify a character sequence
>to use other than "<-" to separate the target from the prereqs.
>(For example, the radically different "<--").  I sound like I'm
>complaining already.  I don't mean to, since I think this is
>really nice.

Just define this in your Makefile.am:

        am__1verbose_CXXLD_1  = @echo "  CXXLD   " $@ "<----" $^; 

probably does not look very nice, but it Works As Expected™.

>I noticed that your patch modifies m4/Makefile.in.   Is that
>correct behavior?

I dunno. To begin, I had to edit Makefile.am to add silent.m4.
The presence of Makefile.in in the git repository however led
me to believe to better edit it too. If it were supposed to be
autogenerated, it would not be in the repository. Unless maybe
regeneration is so awkwardly complex that it would be better
to have the .in file.

Yeah:

>I'm still unclear on the merits of putting
>Makefile.in in the repository at all, but I would think that
>its content in the repository should be automatically
>generated rather than patched.