[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #33138] .PARLLELSYNC enhancement with patch
From: |
Paul Smith |
Subject: |
Re: [bug #33138] .PARLLELSYNC enhancement with patch |
Date: |
Thu, 18 Apr 2013 14:54:23 -0400 |
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.
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, (continued)
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Eli Zaretskii, 2013/04/16
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Paul Smith, 2013/04/16
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Eli Zaretskii, 2013/04/17
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Paul Smith, 2013/04/17
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Eli Zaretskii, 2013/04/17
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Paul Smith, 2013/04/17
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, David Boyce, 2013/04/17
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Frank Heckenbach, 2013/04/18
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Paul Smith, 2013/04/18
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Frank Heckenbach, 2013/04/18
- Re: [bug #33138] .PARLLELSYNC enhancement with patch,
Paul Smith <=
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Frank Heckenbach, 2013/04/18
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Paul Smith, 2013/04/28
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, David Boyce, 2013/04/28
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Eli Zaretskii, 2013/04/28
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Eli Zaretskii, 2013/04/28
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Paul Smith, 2013/04/28
- Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch), Paul Smith, 2013/04/28
- Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch), Eli Zaretskii, 2013/04/28
- Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch), Tim Murphy, 2013/04/29
- Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch), Eli Zaretskii, 2013/04/29