Re: [bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Pe 24.11.2013 18:41, "Paul Smith" a scris: > > On Sun, 2013-11-24 at 12:35 +0200, Eddy Petrișor wrote: > > Since you just worked on this, and the new type overwrites in case of > > repetition, does it make sense to overwrite instead of error? I think > > that for profiling this type of behaviour w

Re: [bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

On Sun, 2013-11-24 at 12:35 +0200, Eddy Petrișor wrote: > Since you just worked on this, and the new type overwrites in case of > repetition, does it make sense to overwrite instead of error? I think > that for profiling this type of behaviour would be better. > Sorry, but I didn't understand that

Re: [bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Pe 24.11.2013 11:12, "Paul D. Smith" a scris: > I enhanced the option parsing in make to create a new type of option, that > takes a single string instead of a list of strings. If multiple instances of > that option are provided, each subsequent instance overwrites (instead of adds > to) the pre

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Update of bug #40226 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #10, bug #40226 (project make): Actually, this issue can also be reproduced with a x64 build done using MinGW (from http://mingw-w64.sourceforge.net/). c:Workspacesrcgitmake>gnumake.exe -f Makefile.bug -Otarget Hello gnumake.exe: *** internal error: multiple --sync-mutex option

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #9, bug #40226 (project make): Eli, it looks like the problem is triggered as soon as you have some output generated during the `read_all_makefiles ()` phase, as it causes a call to `prepare_mutex_handle_string ()`. And after reading the Makefiles, `main ()` calls `decode_env

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #8, bug #40226 (project make): Are we going to release 4.01 soon? If not, is the problem serious enough to fix it in the present code? Or can I safely use the Windows binary of 4.0 unaltered? (As I wrote, the problem does not happen in my usage.)

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #7, bug #40226 (project make): Christian: Thanks for the extended explanations. For the record: I don't see this on my system, at least not with the simple recipe you provided. Moreover, the (second) call to `decode_switches`, after `prepare_mutex_handle_string`, never examines

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #6, bug #40226 (project make): I do understand what Christian is saying, but I'm going to rewrite it out of existence rather than fix it :-) ___ Reply to this item at:

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #5, bug #40226 (project make): Paul: If you already see and understand the problem, by all means take it. I didn't yet have time to even build the release ;-). Thanks. ___ Reply to this item at:

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #4, bug #40226 (project make): Eli: unless you want to deal with this one, I'll take it. I noticed a few weeks ago that option parsing currently has no facility for a "single string"; we can only have a list of strings or filenames (e.g., for "-I"). But this doesn't make sense

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #3, bug #40226 (project make): Well, the symptom can even be reproduced without a Makefile... $ /C/Workspace/src/git/make/WinDebug/make -Otarget -f no-Makefile make: no-Makefile: No such file or directory make: *** internal error: multiple --sync-mutex options. Stop. The rea

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #2, bug #40226 (project make): Could you please provide a minimal Makefile and a test case to reproduce the problem you saw? I'm sorry, but I have a difficulty understanding your description of the bug you found in the code; hopefully a test case will help me see the light. Tha

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #1, bug #40226 (project make): Second thought... I see now where the bug is coming from. Some use cases for the stringlist imply it's handled as a null-terminated array: for (pp=output_sync_option->list; *pp; ++pp) Some others iterate up to idx: for (idx = 1; idx <

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

URL: Summary: Weird failure on Windows with OUTPUT_SYNC_TARGET Project: make Submitted by: None Submitted on: Wed 09 Oct 2013 10:27:54 PM UTC Severity: 3 - Normal Item Gr