On Fri, 2013-04-12 at 13:41 +0200, Reinier Post wrote:
Hmm, indeed:
| /tmp % cat Makefile
| %.1:; echo $*.1 for $@ $@
| %.e.1 %.f.1:; echo $*.1 for $@ $@
| %.c.1 %.d.1:; for f in $*.c.1 $*.d.1; do echo $$f for $@ $$f; done
| %.ab.2: %.a.1 %.b.1; cat $+ $@
| %.cd.2: %.c.1 %.d.1; cat $+
On Sun, Apr 28, 2013 at 1:34 AM, Paul Smith psm...@gnu.org 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
terms for this, define
From: Paul Smith psm...@gnu.org
Cc: e...@gnu.org, david.s.bo...@gmail.com, bug-make@gnu.org
Date: Sun, 28 Apr 2013 01:34:44 -0400
On Thu, 2013-04-18 at 22:36 +0200, Frank Heckenbach wrote:
This is useful (to me) because at any time, I know what's running.
([Start] messages minus
Date: Sun, 28 Apr 2013 10:22:40 -0400
From: David Boyce david.s.bo...@gmail.com
Cc: Frank Heckenbach f.heckenb...@fh-soft.de, Eli Zaretskii e...@gnu.org,
bug-make bug-make@gnu.org
So I'd argue for:
-O line (new)
-O job (current -O target)
-O make
Agree about line (assuming I
From: Paul Smith psm...@gnu.org
Cc: bug-make@gnu.org
Date: Sat, 27 Apr 2013 16:58:54 -0400
On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote:
That would be nice, indeed.
OK, pushed.
Thanks! But I see you kept global_dl and the call to dlopen with the
1st argument NULL. What is
Update of bug #37065 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
Fixed Release:None = SCM
Triage Status:
From: Paul Smith p...@mad-scientist.net
Cc: make-...@gnu.org, bug-make@gnu.org
Date: Sat, 27 Apr 2013 12:54:10 -0400
On Sat, 2013-04-27 at 19:17 +0300, Eli Zaretskii wrote:
The .ONESHELL feature is now supported on MS-Windows, for the default
Windows shell (cmd.exe) or compatible
On Sun, 2013-04-28 at 20:19 +0300, Eli Zaretskii wrote:
From: Paul Smith psm...@gnu.org
Cc: bug-make@gnu.org
Date: Sat, 27 Apr 2013 16:58:54 -0400
On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote:
That would be nice, indeed.
OK, pushed.
Thanks! But I see you kept
On Sun, 2013-04-28 at 21:14 +0300, Eli Zaretskii wrote:
From: Paul Smith p...@mad-scientist.net
Cc: make-...@gnu.org, bug-make@gnu.org
Date: Sat, 27 Apr 2013 12:54:10 -0400
On Sat, 2013-04-27 at 19:17 +0300, Eli Zaretskii wrote:
The .ONESHELL feature is now supported on MS-Windows,
From: Paul Smith psm...@gnu.org
Cc: bug-make@gnu.org
Date: Sun, 28 Apr 2013 14:37:29 -0400
On Sun, 2013-04-28 at 20:19 +0300, Eli Zaretskii wrote:
From: Paul Smith psm...@gnu.org
Cc: bug-make@gnu.org
Date: Sat, 27 Apr 2013 16:58:54 -0400
On Sat, 2013-04-27 at 23:00 +0300, Eli
From: Paul Smith psm...@gnu.org
Cc: bug-make@gnu.org
Date: Sun, 28 Apr 2013 15:15:09 -0400
The goal of this code in the if-statement is to implement a special case
allowing ONESHELL to be easier to add in the case where you DO have a
standard shell. In that case, and ONLY in that case, we
On Sun, 2013-04-28 at 22:41 +0300, Eli Zaretskii wrote:
I think the implementation you have is not quite right. I think the
parsing of the @-+ stuff is common across all platforms if we have a
shell, so you don't need the else /* non-posix shell */.
I do need a separate code, because it
From: Paul Smith psm...@gnu.org
Cc: bug-make@gnu.org
Date: Sun, 28 Apr 2013 16:01:05 -0400
I guess I thought you were writing a batch file,
then invoking the shell with the batch file name as the command to run.
E.g., command.com batchfile vs. perl batchfile etc. I am naive
but it seems
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
characters from several parallel sub-makes?
On Thu, 2013-04-18 at 22:36 +0200, Frank Heckenbach wrote:
% make -Omake # same with -Otarget
m:2: recipe for target 'foo' failed
make: *** [foo] Error 1
foo:error
This seems at least strange to me: The conclusion recipe failed is
printed before the reason (the messages from the job).
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 mode when parallel builds are running.
I understand that this will be a change that could be visible (beyond
the collection of
From: Paul Smith psm...@gnu.org
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 mode when parallel builds are
17 matches
Mail list logo
