Bill Cox wrote:
>So here's my related question: "Is it useful to suppress all silencing
>options, and if so,
how should it be invoked?". I'd love to get this
>functionality into the product, and it's not that complex.
Bob Racko wrote:
> It is indeed very powerful to be able to
> stop and start logging of whats happening through a
> section of a recipe for a target - as well as through
> a section of the whole include processing phase.
Logging, tracing and 'debug output' could send one off on
whole new adventures. The input being solicited here is
how do we give the user enough control without
encumbering make or the user and who is that user?
I will start with myself as the user. I am in a big-build
environment where make is 'batched'.
I didn't write most of the makefiles.
No interaction - make runs periodically.
I have to deal with post-mortems.
I start in with getting answers to the following questions:
- what was make doing
- how
did make get here
- what is the 'state' of the machine
- why are we doing this part /now/
Someone on this list might read these questions as redundant
and all having the same answer. I dont.
I saw a few proposals to, for instance, turn-off
the '@' as a way to un-silence the output stream.
I avoid that one because it changes the makefile-writers
intent. Something downstream might be parsing the make
output. It might also be parsing stderr. Un-silencing
suppressions only addresses one of my initial 4 questions too.
I cant partake in many of the tricks others use
(such as redefining SHELL) that alter what comes
out of make because there are already other tools
watching the make output for their own purposes.
If I am going to enable debug/tracing output -
I want to be able to specify:
- what file to send it to or pipe to filter it with (dynamically)
- how much of it I
want to see (and through what sections)
- if -jN is used - which of the parallel job streams this is
Finally I would like to be able to control this without
altering the makefiles themselves or adding switches.
I think it can be done without invasive overhaul to make.
I am only one user.
I am listening for other proposals or suggestions that will aid
maintainers as well as new writers of makefiles.
-bobr