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

> From: Paul Smith > Cc: Frank Heckenbach , bug-make@gnu.org > Date: Sun, 21 Apr 2013 19:30:05 -0400 > > On Fri, 2013-04-19 at 14:09 +0300, Eli Zaretskii wrote: > > > Date: Fri, 19 Apr 2013 11:54:05 +0200 > > > Cc: bo...@kolpackov.net, bug-make@gnu.org > > > From: Frank Heckenbach > > > > > > >

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

> Date: Sat, 27 Apr 2013 13:09:02 +0300 > From: Eli Zaretskii > Cc: f.heckenb...@fh-soft.de, bug-make@gnu.org > > > The basic feature can be tested trivially like this: > > > > all: one two > > > > one two: > > @echo start $@ > > @sleep 1 > > @echo stop $@ > >

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

On Sat, 2013-04-27 at 13:09 +0300, Eli Zaretskii wrote: > Is this intended behavior that these two messages: > > mkfsync:6: recipe for target 'two' failed > gnumake[1]: [two] Error 1 (ignored) > > are separated and wrapped by separate "Entering...Leaving" blocks, > instead of being produced t

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

On Sat, 2013-04-27 at 14:39 +0300, Eli Zaretskii wrote: > The changes needed to make -O work on MS-Windows are now committed to > the master repository, see commits da7df54 and 049f8e8. Please review > and comment. Thanks Eli!! I'll take a look over the next few days. _

Re: .ONESEHLL not working as expected in 3.82

> Date: Mon, 30 Aug 2010 17:09:51 +0100 > From: "Anjum Naseer" > > I have built the 3.82 version of GNU Make using the Microsoft Visual C++ > compiler and it seems to work fine. > However, I cannot get it to work correctly with the .ONESHELL option. > I created a dummy makefile (dummy.mak) with t

[bug #38827] Make tool does not work for pre-build steps with parallel build option

Update of bug #38827 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: This is not a bug. By

[bug #2520] Add option for alternate default makefile

Update of bug #2520 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: This bug seems to have

[bug #38626] make fails on windows with antivirus software

Update of bug #38626 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM Triage Status:

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

Update of bug #37065 (project make): Triage Status:None => Need Info ___ Reply to this item at: ___ Messag

[bug #31150] The make doesn't work on Windows x64 platforms

Update of bug #31150 (project make): Triage Status:None => Need Info ___ Follow-up Comment #1: Hi, Could you perhaps show a minimal Makefile that reproduces the problem? Also, is this a 64-bit

[bug #30730] SHELL does not work correctly on Windows

Update of bug #30730 (project make): Severity: 3 - Normal => 1 - Wish Item Group: Bug => Enhancement Status:None => Later Triage Status:

[bug #24405] BATCH_MODE_ONLY_SHELL configuration fails with unixy shells

Update of bug #24405 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => 3.82 Triage Status:

[bug #20550] Crash with setting SHELL from the commandline

Update of bug #20550 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => 3.82 Triage Status:

[bug #20542] Regression: windows gnumake + MKS shell + Special Shell Chars

Update of bug #20542 (project make): Item Group: Bug => Enhancement Status:None => Works for me Triage Status:None => Need Info

[bug #17433] Enhancement in process creation functions in sub_proc.c

Update of bug #17433 (project make): Severity: 3 - Normal => 1 - Wish Status:None => Fixed Open/Closed:Open => Closed Fixed Release:

[bug #17277] Pathes longer than 128 Chars fail with make under windows

Update of bug #17277 (project make): Open/Closed:Open => Closed Fixed Release:None => 3.82 Triage Status:None => Verified

[bug #16476] WINDOWS32 vs. HAVE_ANSI_COMPILER macros

Update of bug #16476 (project make): Open/Closed:Open => Closed Fixed Release:None => 3.82 ___ Follow-up Comment #6: I'm closing this bug b

[bug #7201] Windows Path search works incorrectly

Update of bug #7201 (project make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #4: I'm closing this bug be

Re: .ONESEHLL not working as expected in 3.82

> From: Paul Smith > Cc: make-...@gnu.org, bug-make@gnu.org > Date: Sat, 27 Apr 2013 12:54:10 -0400 > > Also, I wonder if you have a few minutes to go through the open Windows > bugs in Savannah and make a comment or whatever to those which are still > waiting (some are waiting for other people,

Re: .ONESEHLL not working as expected in 3.82

On Sat, 2013-04-27 at 20:55 +0300, Eli Zaretskii wrote: > Note: there's one more major feature in current git repo that needs to > be made available on Windows: dynamic loading of extensions. That is > my highest priority for Make todo list. Yes. I wonder if there are features of gnulib which ma

Re: .ONESEHLL not working as expected in 3.82

> From: Paul Smith > Cc: make-...@gnu.org, bug-make@gnu.org > Date: Sat, 27 Apr 2013 14:28:18 -0400 > > On Sat, 2013-04-27 at 20:55 +0300, Eli Zaretskii wrote: > > Note: there's one more major feature in current git repo that needs to > > be made available on Windows: dynamic loading of extension

Re: .ONESEHLL not working as expected in 3.82

I took with make-w32 list off. On Sat, 2013-04-27 at 22:18 +0300, Eli Zaretskii wrote: > I added a similar facility to Gawk, but there a problem was much > simpler, because Gawk itself was tracking the loaded extensions in > platform-independent code. So my emulation of dlopen didn't need to > su

Re: .ONESEHLL not working as expected in 3.82

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sat, 27 Apr 2013 15:32:22 -0400 > > Well, we already maintain a list of modules that are loaded in > the .LOADED variable. Although it's not written like that today, I have > no problem changing the code to check that variable to see whether the

Re: .ONESEHLL not working as expected in 3.82

On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote: > That would be nice, indeed. OK, pushed. You should be able to simply write a new load_objects() function and drop it in. Or put it into a w32 file or whatever. ___ Bug-make mailing list Bug-m

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

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 "[End]" messages.) > > > > Thanks, this is the reason I was looking for; that use-case wasn't clear > > to me based on the previous em

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

Update of bug #37065 (project make): Triage Status: Need Info => None ___ Follow-up Comment #4: Hi Eli; there's a makefile attached. It's maybe not everything we'd wish for in a repro case but i

Re: Quirk with rules producing multiple output files

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 %.