>> ---------- Origional message ----------
>> Subject: A way of finding out what went wrong when a build fails
>>
>> I like the dump output from make - it contains a lot of good
>> stuff.
refinement: When I mentioned 'dump' I had meant the output of -p
On Sunday, March 2, 2008 9:47:35 AM Bill Cox wrote:
>> I would like to be selective about the dump output under certain conditions.
>> If I can avoid it - I would like to be able to specify the conditions
>> without having to pepper the makefiles with additional code.
>
>The simplest condition that I can think of would be to say 'on
>command error', which would trigger make to save its state when a
>command error
occurs,
Would this be the persistent state that it is saving
or the -p switch output? Are they supposed to be the same thing?
IE is it the intent that the output from -p
be re-readable by gmake at some time in the future?
> and it would start to log *everything* as if
>the various silent options were all false.
Ahh so assuming the -k switch was active. OK
I was just trying to catch the about-to-give-up
terminal condition - but I can see your situation too.
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.
>An alternative condition
>might be 'on make error', and so on.
Alright - though what you propose is not a
function
or a variable and it is additional syntax to parse this
in makefiles. Can we avoid this?
Can we do this without having to train 400+ 'seasoned'
engineers in my company and 1000+ writers of
contributed code in the new syntax?
>I too have used make on large Makefile trees, and I once submitted
>a patch which would negate all of the silencing options. One version
>had a new option called '--always-print-commands' to activate it.
I am avoiding new options or switches in favor of a make variable
which I can set on the command line or in the environment
or explicitly set in some included makefile - perhaps to different
values depending on which target is being produced.
If I put the variable in the environment then all the sub-makes get it.
I would still be able to use overrides.
This is controllable behavior.
I am considering initially, that the value of this variable
is a filename in which to store the output (of the -p).
If the filename begins with a vertical bar '|' then it is taken
as a command or script to pipe output to/through. That way I can
build on the strengths of other tools like grep or gawk
to filter just the variables or just the rules.
I can see this convention being generalized to other places in make
where an output filename is expected. Perhaps to catch
other multiple-stream problems as well (such as -jN outputs)
... but lets leave that to a separate discussion.
> If
>this seems useful to the list, I could dust off the patch and resubmit.
>
>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.
It too merits a separate thread.
>Bill
-bobr