On Thu, 2013-04-18 at 20:36 +0200, Frank Heckenbach wrote:
> And with my progress mechanism, that's exactly what I want. In my
> case it'd look like this:
>
> [Start] Compiling foo.c
> [Start] Compiling bar.c
> # time passes
> foo.c: some error
> # time passes
> bar.c: some error
> # time passes
> [End] Compiling bar.c
> # time passes
> [End] Compiling foo.c
>
> This is useful (to me) because at any time, I know what's running.
> ("[Start]" messages minus "[End]" messages.)
Thanks, this is the reason I was looking for; that use-case wasn't clear
to me based on the previous email.
> > Probably we'll want to allow the user to
> > have more control over it, as well. Maybe a similar flag that lets you
> > choose whether to trace on a per-target or per-make basis.
>
> I think it should in principle be possible without requiring the
> user to specify any more options.
I was thinking more that the user may want to not want all the
enter/leave output even if it is ambiguous from a programmatic sense: I
know where my code lives and so if I see the my_foo.o fails, I know that
the my_foo.c file lives in src/my/my_foo.c. I might prefer to see a
cleaner output from make and rely on my innate knowledge of the codebase
to navigate.
But maybe you'd still like to see the per-make enter/leave, even if
you're running with -Otarget.
> But it would be some work, requiring make to keep track of which
> directory message was output last, delay the "leaving" message in case
> the next one will be "entering" the same directory etc., and
> synchronize this among recursive makes in the different modes.
Synchronization between recursive makes is not something I want to get
into. As long as the messages are coherent within a single make
instance, either before/after everything the make instance does or
before/after each target (or job, if that is needed) that's enough for
me.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
