Re: GOP-PROP 9: behavior of make doc

[Keith OHara]

Graham Percival <graham <at> percival-music.ca> writes:

> That proposal failed to achieve clarity and consensus
> within a month, mostly due to the proposal being too broad.

By "to broad" I guess you mean that the old proposal affected `make bin`,
which doesn't suffer the sea-of-output problem.
The proposal was pretty clear, but required careful reading.

They way I misread the old one was to assume that the goal:

> If there are build problems, then it should be easier to find out
> why it’s failing. 
[...]
> ** Sea of output

would be directly addressed in the 

> ** Proposal details
> 

However, the solidly-defined details pretty much redirect the sea
of output to log files, similar to 

  make 2>err.log || echo "failed; see err.log"

Maybe that is the first step to sort through the `make` process, and 
the *real* benefit comes from fishing the important bits out of the sea:

>       The user may optionally request additional output to be
> printed; this is controlled with the VERBOSE=x flag. In such
> cases, all output will still be written to log files; the console
> output is strictly additional to the log files.
>

If "all output" means the current verbose output, it might be hard
to both get all output in log files, and desired output on screen.
The easier way would be to tell the sub-processes how verbose to be,
and tee all of stderr to file and screen.
If "all output" is just what we asked for with the VERBOSE=x flag,
then the current verbose output could be requested on a second 
`make` if the desired output didn't tell us enough.

>     * Both stderr and stdout will be saved in *.log. 

Probably like you mean "in /the same/ *.log file".

> However, there is a danger in this approach, that vital error
> messages can also be lost, 

Maybe Phil could play it safe and retain the old make rules that run 
the sub-processes in verbose mode.  Then it should be safe to make new 
make rules that run the sub-processes to report errors/warnings only 
(and maybe prefixed with @ so they don't echo the command-line).
This might be awkward when make(1) descends to subdirectories and builds
the default target there, or with whatever 'stepmake' is.

This does seem hard to define in advance before seeing what is possible.

Have I said recently how much I really really like `make bin` ?