Issue 5568: make build output terse by default

https://sourceforge.net/p/testlilyissues/issues/5568/

The goal is to show progress without burying warnings and errors in
the noise of long commands.

Options VERBOSE=1 and SILENT=1 make the output more like the usual
"make" and "make -s" (respectively).

The verbosity level affects the options that are passed to some
commands, but there is room for improvement in this area.

[lemzwerg, 2019-10-04 23:23:19]

Thanks for your efforts.  Some comments.

* What about using the automake format, for example

    CC     foo.o
    CCLD   bar
    FLEX   baz.c

  See the automake info manual, `Silencing Make', for more.

  In particular I think that the `Making ' string can be completely omitted.

* I can imagine that it makes more sense to show paths (if at all) relative to
the top-level build or source directory.  This would allow a quick comparison of
compilation logs between two different installations.

* The idea of showing the type of input file is nice; this might be a useful
addition to showing the processing program.  I'm not sure about that, however.

[Dan Eble, 2019-10-05 02:05:49]

On 2019/10/04 23:23:19, lemzwerg wrote:

> * I can imagine that it makes more sense to show paths (if at
> all) relative to the top-level build or source directory.  This
> would allow a quick comparison of compilation logs between two
> different installations.

It should be the build directory.  If you know how to achieve it
simply, I'll run a search and replace.  When I started, it wasn't
obvious how to achieve it, and then after I finished modifying
every rule everywhere, I lost interest in further research.

[lemzwerg, 2019-10-05 10:57:56]

> It should be the build directory.  If you know how to achieve it
> simply, I'll run a search and replace.

What about doing

  $(subst $configure-builddir,,$(abspath ...))

to strip off the builddir prefix?  This is untested, however

[Dan Eble, 2019-10-05 12:56:02]

add ly_progress to centralize formatting

[Dan Eble, 2019-10-05 12:59:57]

s&r ly_info -> ly_progress

[Dan Eble, 2019-10-05 13:26:24]

On 2019/10/04 23:23:19, lemzwerg wrote:
> * The idea of showing the type of input file is nice; this might be a useful
> addition to showing the processing program.  I'm not sure about that, however.

I wouldn't put up much of a fight if someone demanded removing
it, but I find it helpful, especially during the doc build, which
is not as familiar to me as "foo.o < cc".

Below is an example of where a person not thoroughly familar with
the build process might be helped by having the type of input
logged.  One could argue that at this point, someone wondering
what make is running could use VERBOSE=1, but it's still simpler
to find "< tex" than to work backward from the actual command to
its coded form in the makefile.

$(outdir)/%.tex:  %.lytex
	$(call ly_progress,Making,$@,< lytex)
	$(buildscript-dir)/run-and-check "$(LILYPOND_BOOK_COMMAND) --pdf -o $(outdir)
$<"  "$*.lytex.log"

$(outdir)/%.tex:  %.tex
	$(call ly_progress,Making,$@,< tex)
	$(LILYPOND_BOOK_COMMAND) --pdf -o $(outdir) $<
--
Dan

[lemzwerg, 2019-10-05 13:44:54]

We are getting nearer, thanks :-)

The next thing I notice is that `ly_progress` is (always?) called as

  $(call ly_progress,Making,$@,<comment>)

What about using `$$@` (or something like that to delay expansion) in the
definition of `ly_progress` and omitting `Making` as an argument, too?  This
would give

  $(call ly_progress,<comment>)

instead.

[Dan Eble, 2019-10-05 14:19:29]

On 2019/10/05 13:44:54, lemzwerg wrote:
> We are getting nearer, thanks :-)
>
> What about using `$$@` (or something like that to delay expansion) in the
> definition of `ly_progress` and omitting `Making` as an argument, too?  This
> would give
>
>   $(call ly_progress,<comment>)

Too rigid.  You previously expressed a desire to see something like

    CC      foo.o

And that is not a bad idea, but is one that I view as less
valuable than other things I could work on.  To achieve that, the
process/tool needs to remain an argument of ly_progress.

There is also a question of whether it ever makes sense to
announce progress at intermediate points in a multi-command
recipe, and I think it might, even though I haven't done it
anywhere in this contribution.  To support that, the target needs
to remain an argument of ly_progress.

Also, there might be cases where $@ is not the most salient thing
to log in the progress message.  I'm thinking of cases like
timestamp files and phony targets.  There might be some of these
in the current contribution, but I did not want to spend time
polishing to that extent.

[lemzwerg, 2019-10-05 14:39:35]

> > What about using `$$@` (or something like that to delay expansion) in
> > the definition of `ly_progress` and omitting `Making` as an argument,
> > too?  This would give
> >
> >   $(call ly_progress,<comment>)
> 
> Too rigid.  [...]

Ok.