: I've tested your changes and so far "-O job" works for my use cases.
I shouldn't have written that. :-( Shortly afterwards, I found a bug
or perhaps two:
foo:
@echo foo
+@echo bar
(a)
% make -Ojob
foo
bar
foo
(b)
% make -Otarget
bar
foo
As you see, (a) "-Ojob" writes "foo" tw
> From: Paul Smith
> Cc: reinp...@win.tue.nl, bug-make@gnu.org
> Date: Fri, 03 May 2013 16:51:47 -0400
>
> > I think enabling [-O] by default will be a no-brainer if/when we come up
> > with a way to get it to produce the same output as without -j. IOW,
> > run a parallel build, but output its r
Paul Smith wrote:
> I went a different way: I modified the child_error() function so that if
> there was an output-sync file, the error message would be written to the
> end of that file instead of printed directly. This way when the output
> is shown to the user she sees the entire thing, includ
Eli Zaretskii wrote:
> > From: Paul Smith
> > Cc: bug-make@gnu.org
> > Date: Sun, 28 Apr 2013 22:03:39 -0400
> >
> > Now that we seem to have a workable solution for output synchronization
> > for both POSIX and Windows systems, I wonder if we shouldn't consider
> > enabling it as the default mo
Paul Smith wrote:
> On Sun, 2013-04-28 at 20:00 +0300, Eli Zaretskii wrote:
> > > I've pushed a change to add a new argument to the -O/--output-sync
> > > option, "job", to write output after each line of the recipe.
> >
> > What is its purpose? To avoid mixing in the same screen line
> > charac
David Boyce wrote:
> On Sun, Apr 28, 2013 at 1:34 AM, Paul Smith wrote:
> > I'm not excited about that term ("job"); it's kind of accurate, but in
> > the documentation for example we're really mushy about exactly what a
> > "job" is, vs. a "recipe" or a "command line" etc. I'd like to pick some
On Fri, 2013-05-03 at 23:12 +0300, Eli Zaretskii wrote:
> > the "start" and "end" will have other stuff (not just the other targets
> > in that sub-make, but ANY other targets that happen to finish during
> > that time) between them.
>
> This last part (about ANY other targets) is not what I thoug
On Fri, 2013-05-03 at 16:16 +0300, Eli Zaretskii wrote:
> > From: Paul Smith
> > Date: Fri, 03 May 2013 08:57:57 -0400
> > Cc: bug-make@gnu.org
> >
> > I think having this facility built into make is a win, especially as
> > parallel builds become predominant. I would be even more happy about it
> From: Paul Smith
> Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
> Date: Fri, 03 May 2013 15:30:18 -0400
>
> On Fri, 2013-05-03 at 21:15 +0300, Eli Zaretskii wrote:
> > > This will ensure that output from lines before the recursive make will
> > > be shown before the targets in the recursiv
On Fri, 2013-05-03 at 21:15 +0300, Eli Zaretskii wrote:
> > This will ensure that output from lines before the recursive make will
> > be shown before the targets in the recursive make. It's not 100%
> > identical but I can't see any way to do better.
>
> Why isn't it identical?
It's not identic
> From: Paul Smith
> Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
> Date: Fri, 03 May 2013 12:55:26 -0400
>
> Suppose we do this: if we're about to invoke a line marked recursive and
> we're in -Otarget mode, then before we run it we'll show the current
> contents of the temp file (using the
I have a solution for this problem that I think will work well, and will
be simple to implement.
Suppose we do this: if we're about to invoke a line marked recursive and
we're in -Otarget mode, then before we run it we'll show the current
contents of the temp file (using the normal synchronized ou
On Fri, May 3, 2013 at 8:57 AM, Paul Smith wrote:
> On Fri, 2013-05-03 at 14:02 +0200, Reinier Post wrote:
>> Using a separate utility seems to be a clean
>> solution here, and that is fact how it was originally done:
>>
>> http://lists.gnu.org/archive/html/bug-make/2011-04/msg00018.html
There'
On Fri, 2013-05-03 at 16:13 +0300, Eli Zaretskii wrote:
> > The two problems I discovered and fixed are:
>
> No comments, so I went ahead and pushed these changes (see commit
> a66469e).
Thanks Eli. I hadn't gotten around to examining those comments in
detail. In general I was OK with what I r
> From: Paul Smith
> Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
> Date: Fri, 03 May 2013 09:08:27 -0400
>
> You're concentrating on the one recursive make target and saying
> "this doesn't follow the rule", while I'm concentrating on all
> targets in the sub-make and saying "let's make sur
I've done the "external utility" solution and only because we absolutely
had no other choice - it's not much fun and can be done much more
effectively by make itself.
Regards,
Tim
On 3 May 2013 14:16, Eli Zaretskii wrote:
> > From: Paul Smith
> > Date: Fri, 03 May 2013 08:57:57 -0400
> > Cc:
> From: Paul Smith
> Date: Fri, 03 May 2013 08:57:57 -0400
> Cc: bug-make@gnu.org
>
> I think having this facility built into make is a win, especially as
> parallel builds become predominant. I would be even more happy about it
> if we can get it to the point where it can be enabled by default,
> Date: Tue, 30 Apr 2013 22:04:52 +0300
> From: Eli Zaretskii
>
> I ran all of the load and loadapi tests in the test suite and found a
> couple of problems in the current implementation that were based on
> unportable assumptions. The solutions touch to some extent the
> platform independent co
On Fri, 2013-05-03 at 15:22 +0300, Eli Zaretskii wrote:
> > The issue of how -Otarget handles recursive make is, IMO, a detail
> > necessitated by the architecture of recursive make invocations. I don't
> > know that it's feasible to reflect that detail in the name.
>
> It is a detail that IMO si
On Fri, 2013-05-03 at 14:02 +0200, Reinier Post wrote:
> Reading this discussion, as a bystander I can't help wondering whether
> the addition of -O is worthwhile. Unix tools are supposed to be
> small and dedicated. Using a separate utility seems to be a clean
> solution here, and that is fact ho
> From: Paul Smith
> Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
> Date: Fri, 03 May 2013 07:47:09 -0400
>
> The way the user experiences the -Ojob option's results is that the
> output of every line of each recipe is dumped as soon as that line is
> complete.
I would suggest -Oline or -Oc
Reading this discussion, as a bystander I can't help wondering whether
the addition of -O is worthwhile. Unix tools are supposed to be
small and dedicated. Using a separate utility seems to be a clean
solution here, and that is fact how it was originally done:
http://lists.gnu.org/archive/html/
On Fri, 2013-05-03 at 09:50 +0300, Eli Zaretskii wrote:
> > From: Paul Smith
> > Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
> > Date: Thu, 02 May 2013 16:21:36 -0400
> >
> > The one and only difference between them is that when running a
> > recursive make, -Otarget WILL NOT capture the ou
23 matches
Mail list logo
