Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

2013-04-28 Thread Eli Zaretskii
> 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 mode when parallel builds are running.

Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

2013-04-28 Thread Paul Smith
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 ou

Re: [bug #33138] .PARLLELSYNC enhancement with patch

2013-04-28 Thread Paul Smith
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 jo

Re: [bug #33138] .PARLLELSYNC enhancement with patch

2013-04-28 Thread Paul Smith
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-

Re: .ONESEHLL not working as expected in 3.82

2013-04-28 Thread Eli Zaretskii
> From: Paul Smith > 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 " vs. "perl " etc. I am naive > but it seems like that should work

Re: .ONESEHLL not working as expected in 3.82

2013-04-28 Thread Paul Smith
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, be

Re: .ONESEHLL not working as expected in 3.82

2013-04-28 Thread Eli Zaretskii
> From: Paul Smith > 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 remove

Re: .ONESEHLL not working as expected in 3.82

2013-04-28 Thread Eli Zaretskii
> From: Paul Smith > 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 > > > Cc: bug-make@gnu.org > > > Date: Sat, 27 Apr 2013 16:58:54 -0400 > > > > > > On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretski

Re: .ONESEHLL not working as expected in 3.82

2013-04-28 Thread Paul Smith
On Sun, 2013-04-28 at 21:14 +0300, Eli Zaretskii wrote: > > From: Paul Smith > > 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 def

Re: .ONESEHLL not working as expected in 3.82

2013-04-28 Thread Paul Smith
On Sun, 2013-04-28 at 20:19 +0300, Eli Zaretskii wrote: > > From: Paul Smith > > 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 g

Re: .ONESEHLL not working as expected in 3.82

2013-04-28 Thread Eli Zaretskii
> From: Paul Smith > 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 replacements, in the

[bug #37065] $(wildcard dir/*/.) is wrong (worked fine in 3.81)

2013-04-28 Thread Eli Zaretskii
Update of bug #37065 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM Triage Status:

Re: .ONESEHLL not working as expected in 3.82

2013-04-28 Thread Eli Zaretskii
> From: Paul Smith > 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 the pur

Re: [bug #33138] .PARLLELSYNC enhancement with patch

2013-04-28 Thread Eli Zaretskii
> Date: Sun, 28 Apr 2013 10:22:40 -0400 > From: David Boyce > Cc: Frank Heckenbach , Eli Zaretskii , > bug-make > > So I'd argue for: > > -O line (new) > -O job (current -O target) > -O make Agree about "line" (assuming I understood what it means), but disagree about renaming "target": it is

Re: [bug #33138] .PARLLELSYNC enhancement with patch

2013-04-28 Thread Eli Zaretskii
> From: Paul Smith > 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 "[En

Re: [bug #33138] .PARLLELSYNC enhancement with patch

2013-04-28 Thread David Boyce
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 > terms for this, define th