> Date: Sun, 05 May 2013 20:17:50 +0300
> From: Eli Zaretskii
> Cc: bug-make@gnu.org
>
> > From: Paul Smith
> > Cc: bug-make@gnu.org
> > Date: Sun, 05 May 2013 12:56:48 -0400
> >
> > On Sun, 2013-05-05 at 19:36 +0300, Eli Zaretskii wrote:
> > > However, I wonder what was the reason for splittin
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Sun, 05 May 2013 12:56:48 -0400
>
> On Sun, 2013-05-05 at 19:36 +0300, Eli Zaretskii wrote:
> > However, I wonder what was the reason for splitting the definition of
> > GMK_EXPORT in two, and putting each part in a different file.
>
> Well, beca
On Sun, 2013-05-05 at 19:36 +0300, Eli Zaretskii wrote:
> However, I wonder what was the reason for splitting the definition of
> GMK_EXPORT in two, and putting each part in a different file.
Well, because the gnumake.h file is intended to be installed into the
user's /usr/include or similar, and
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Sat, 04 May 2013 17:51:05 -0400
>
> Eli, I did some cleanup in job.c to try to make things simpler and
> reduce duplication. I tried to be careful but it's quite possible I did
> something to disrupt the Windows version again. It's up to you if
On Fri, 2013-05-03 at 12:55 -0400, Paul Smith wrote:
> 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
> output function).
I've implemented thi
> From: Paul Smith
> Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
> Date: Fri, 03 May 2013 17:17:44 -0400
>
> -O in no way changes that behavior, all it does is ensure that output
> from any individual line or target of the recipe will not interfere with
> any other individual line or target
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
> 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
> 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
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
> 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
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
> 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 output of the sub-make,
> leaving whatever it prints going to the same
On Thu, 2013-05-02 at 20:24 +0300, Eli Zaretskii wrote:
> The "desired results" in my original use case are that the output of
> remaking each target is shown as one chunk in the order in which it is
> expected, i.e. from the first command to the last. "Remaking a
> target", a.k.a. "recipe" in thi
> From: Paul Smith
> Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
> Date: Thu, 02 May 2013 08:21:23 -0400
>
> > > Now, if you do nothing special for recursive make, you'll get no output
> > > from the entire build until it is completely done, because all the
> > > output from the recursive m
Eli Zaretskii writes:
> > If you want different behavior you can change your rule to use "+" on
> > the two echo lines, so that they're also considered recursive and not
> > saved up.
>
> If I do that, the echo from rec1 and rec2 mix up:
>
> D:\gnu\make-3.82.90_GIT_2013-05-01>gnumake -f mkfsyn
One optimisation I have thought of in the past for this situation would be
to allow a single "job" to hold onto the lock when it obtained it.
This way it could output directly to the console while all other jobs would
have to buffer. When it released, the next job lucky enough to grab the
lock mi
> From: Paul Smith
> Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
> Date: Wed, 01 May 2013 16:27:58 -0400
>
> If your recipe normally runs for 5 seconds (say) and it continually
> generates output during that time, then yes, certainly the -O feature
> will result in choppiness because instea
On Wed, 2013-05-01 at 22:08 +0300, Eli Zaretskii wrote:
> Yes. But I thought the change was about -Otarget, not -Ojob. Stefano
> was complaining about a plain -O, so -Ojob is not what was his
> problem.
Yes, it is about -Otarget. As I said, I added -Ojob output "just for
completeness". The imp
> From: Paul Smith
> Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
> Date: Wed, 01 May 2013 14:41:25 -0400
>
> If you want different behavior you can change your rule to use "+" on
> the two echo lines, so that they're also considered recursive and not
> saved up.
If I do that, the echo from
> From: Paul Smith
> Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
> Date: Wed, 01 May 2013 14:41:25 -0400
>
> > Unfortunately, the delays are still here.
>
> Very odd. This is the test program I used; can you verify:
>
> recurse: ; $(MAKE) -f $(firstword $(MAKEFILE_LIST)) all
> all: 2
On Wed, 2013-05-01 at 18:26 +0300, Eli Zaretskii wrote:
> You forgot to make the same change in the WINDOWS32 branch. I did
> that in commit a87ff20.
Sorry, I missed that.
> > This should be fixed now. Those who use recursive makefiles and were
> > seeing annoying delays in output with -O, plea
On 05/01/2013 05:26 PM, Eli Zaretskii wrote:
>
> Unfortunately, the delays are still here.
>
I can say they're no longer there *in my use case*; I haven't tested
other use cases though. Hope this is sorted out soon...
Thanks,
Stefano
___
Bug-make mai
> From: Paul Smith
> Date: Wed, 01 May 2013 08:04:08 -0400
> Cc: bug-make@gnu.org
>
> > This should work very well with -Otarget then, except for the
> > colorization/highlighting issue... once it works as expected. I'll look
> > into this issue later and I would be interested to see your experi
Hi Paul.
On 05/01/2013 02:04 PM, Paul Smith wrote:
> On Tue, 2013-04-30 at 10:39 -0400, Paul Smith wrote:
>> On Tue, 2013-04-30 at 16:04 +0200, Stefano Lattarini wrote:
>>> On 04/30/2013 03:37 PM, Paul Smith wrote:
Just to be clear, you're saying that the testsuite runs as one long
opera
On Tue, 2013-04-30 at 10:39 -0400, Paul Smith wrote:
> On Tue, 2013-04-30 at 16:04 +0200, Stefano Lattarini wrote:
> > On 04/30/2013 03:37 PM, Paul Smith wrote:
> > > Just to be clear, you're saying that the testsuite runs as one long
> > > operation, updating one target, and the recipe invokes one
On Tue, 2013-04-30 at 16:04 +0200, Stefano Lattarini wrote:
> On 04/30/2013 03:37 PM, Paul Smith wrote:
> > Just to be clear, you're saying that the testsuite runs as one long
> > operation, updating one target, and the recipe invokes one test script,
> > right?
> >
> No; the testsuite runs as a re
Hi Paul.
On 04/30/2013 03:37 PM, Paul Smith wrote:
> Just to be clear, you're saying that the testsuite runs as one long
> operation, updating one target, and the recipe invokes one test script,
> right?
>
No; the testsuite runs as a recursive make invocation (yes, this is sadly
truly needed in or
Just to be clear, you're saying that the testsuite runs as one long
operation, updating one target, and the recipe invokes one test script,
right? I can see how that environment might be problematic for this new
feature. It works much better for lots of smaller targets.
However, you could avoid
On 04/30/2013 01:22 PM, Tim Murphy wrote:
> I know this isn't going to go down all that well, but I really think the
> output should be annotated in such a way that colourisation could be
> applied to the log file after a build has already finished.
>
While this might (underline "might" ;-) be an i
I know this isn't going to go down all that well, but I really think the
output should be annotated in such a way that colourisation could be
applied to the log file after a build has already finished.
e..g you load a makefile into VIM - it can colourise it. Or a bit of C
source code. Why not the
On 04/30/2013 12:01 PM, Tim Murphy wrote:
> What I mean is that:
>
> ./make -Otarget
>
> might be a good interactive default rather than -Omake.
>
I wasn't even aware of those differences; as of latest Git commit
'moved-to-git-46-g19a69ba', I don't see them documented in either
the help screen, t
On 04/30/2013 11:55 AM, Tim Murphy wrote:
> I'm guessing here but I imagine the main problem comes with delaying the
> results of submakes?
>
I think so, yes. The Distributed Make from Sun implements a similar
output synchronization feature, and doesn't have the output delay problems
I have experi
What I mean is that:
./make -Otarget
might be a good interactive default rather than -Omake.
Colouring is another issue which I would imagine could be done another way
to let us have the best of both worlds.
Regards,
Tim
On 30 April 2013 10:55, Tim Murphy wrote:
> I'm guessing here but I i
I'm guessing here but I imagine the main problem comes with delaying the
results of submakes?
I haven't tested to see if this is how the new feature works or not. I
don't think it's completely necessary to keep all output from one submake
together. so turning that off might make things more intera
I'm sorry to say that the new -O option can interact *badly*
with Automake-generated parallel testsuites (at least when they
are being run "interactively", that is, with the output of make
connected to a tty).
Let me elaborate a little (if you still have doubts or objections
after reading the cons
39 matches
Mail list logo
