[bug #42833] Prunes targets with pattern rules for no obvious reason

Additional Item Attachment, bug #42833 (project make): File name: test.mkSize:18 KB ___ Reply to this item at: ___ Message sent

[bug #42833] Prunes targets with pattern rules for no obvious reason

URL: Summary: Prunes targets with pattern rules for no obvious reason Project: make Submitted by: glandium Submitted on: Wed 23 Jul 2014 11:32:34 AM GMT Severity: 3 - Normal

Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time

On Thu, Feb 06, 2014 at 12:42:46PM +0200, Eli Zaretskii wrote: > > Date: Thu, 6 Feb 2014 18:54:33 +0900 > > From: Mike Hommey > > Cc: psm...@gnu.org, bug-make@gnu.org, bo...@kolpackov.net > > > > The point is, batch shell mode only flag is advertized in config.h a

Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time

On Thu, Feb 06, 2014 at 10:45:39AM +0200, Eli Zaretskii wrote: > > Date: Thu, 6 Feb 2014 16:01:06 +0900 > > From: Mike Hommey > > Cc: psm...@gnu.org, bug-make@gnu.org, bo...@kolpackov.net > > > > I gave multiple examples already. It doesn't require backslashes

Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time

On Thu, Feb 06, 2014 at 07:44:11AM +0200, Eli Zaretskii wrote: > > Date: Thu, 6 Feb 2014 06:23:46 +0900 > > From: Mike Hommey > > Cc: psm...@gnu.org, bug-make@gnu.org, bo...@kolpackov.net > > > > On Wed, Feb 05, 2014 at 11:10:11PM +0200, Eli Zaretskii wrote: >

Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time

On Thu, Feb 06, 2014 at 06:23:46AM +0900, Mike Hommey wrote: > On Wed, Feb 05, 2014 at 11:10:11PM +0200, Eli Zaretskii wrote: > > > Date: Thu, 6 Feb 2014 05:58:08 +0900 > > > From: Mike Hommey > > > Cc: psm...@gnu.org, bug-make@gnu.org, bo...@kolpackov.net > >

Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time

On Wed, Feb 05, 2014 at 11:10:11PM +0200, Eli Zaretskii wrote: > > Date: Thu, 6 Feb 2014 05:58:08 +0900 > > From: Mike Hommey > > Cc: psm...@gnu.org, bug-make@gnu.org, bo...@kolpackov.net > > > > But the thing is there is still inconsistency in how things en

Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time

On Wed, Feb 05, 2014 at 05:42:17PM +0200, Eli Zaretskii wrote: > > Date: Wed, 5 Feb 2014 16:30:25 +0900 > > From: Mike Hommey > > Cc: Eli Zaretskii , bug-make@gnu.org > > > > > I agree about using backslashes as directory separators, that obviously > > &g

Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time

On Tue, Feb 04, 2014 at 06:54:36PM +0200, Eli Zaretskii wrote: > Why are you using backslashes in file names when your shell is a Unixy > shell? That makes little sense to me, and I don't see why Make on > Windows should support such use. Unixy shells are supposed to get > Unixy file names with f

Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time

On Tue, Feb 04, 2014 at 12:28:53PM -0500, Paul Smith wrote: > On Tue, 2014-02-04 at 18:54 +0200, Eli Zaretskii wrote: > > > Another issue is with backslashes in paths. > > > > > > For example: > > > $ cat < foo.mk > > > foo: > > > grep foo < foo\\bar > > > EOF > > > > > > (Note the < is j

Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time

On Sat, Feb 01, 2014 at 11:29:19AM +0200, Eli Zaretskii wrote: > > From: Paul Smith > > Cc: Mike Hommey , mh+savan...@glandium.org, > > bo...@kolpackov.net, bug-make@gnu.org > > Date: Fri, 31 Jan 2014 10:59:13 -0500 > > > > My question, or _challenge_ i

Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time

On Fri, Jan 31, 2014 at 11:37:47AM +0200, Eli Zaretskii wrote: > > Date: Fri, 31 Jan 2014 09:14:32 + > > From: Mike Hommey > > > > This is a different approach to the problem, as suggested by Paul: this > > triggers batch mode shell when there are double q

[bug #41246] Allow to switch shell batch mode at runtime instead of build time

Follow-up Comment #10, bug #41246 (project make): This is a different approach to the problem, as suggested by Paul: this triggers batch mode shell when there are double quotes in the recipe. Note this doesn't quite work around all the problems that the previous patch did solve when adding .BATCH_

[bug #41246] Allow to switch shell batch mode at runtime instead of build time

Follow-up Comment #7, bug #41246 (project make): I just realized I said something very wrong: BATCH_MODE_ONLY_SHELL is not all all like ONESHELL. It still runs a shell per recipe line. Sorry for the confusion. ___ Reply to this item at:

[bug #41246] Allow to switch shell batch mode at runtime instead of build time

Follow-up Comment #6, bug #41246 (project make): The command line size limit is in the order of several megabytes nowadays on Linux. It used to be much less, though. Arguably, if this was a wanted feature, you would likely have heard people complain when the command line size limit was lower.

[bug #41246] Allow to switch shell batch mode at runtime instead of build time

Follow-up Comment #4, bug #41246 (project make): > why not .BATCH_MODE_ONLY_SHELL, btw? Apart from making it the same as the macro, the "only" feels too much for a target name. I don't care that much for the name, though, your pick. > which should at least be documented in the manual. Would you

[bug #41246] Allow to switch shell batch mode at runtime instead of build time

Follow-up Comment #1, bug #41246 (project make): I happen to have not been logged in when I submitted, but this bug and patch are mine :) ___ Reply to this item at: _

[bug #40322] Interrupting a build with CTRL-C doesn't kill subprocesses

Follow-up Comment #8, bug #40322 (project make): Please close. I /think/ all the issues i've had so far are due to our intermediate processes not handling things well. I'll reopen if it turns out there is something wrong with make. ___ Repl

[bug #40503] Shebang detection is flawed

URL: Summary: Shebang detection is flawed Project: make Submitted by: glandium Submitted on: Thu 07 Nov 2013 01:01:58 AM GMT Severity: 3 - Normal Item Group: Bug

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #18, bug #40241 (project make): >From several tests, it does seem to work, despite it not following BATCH_MODE_ONLY_SHELL, which is probably due to sh.exe not screwing up with quotes with unixy paths. ___ Reply to this ite

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #16, bug #40241 (project make): Using single quotes seems to be another workaround. ___ Reply to this item at: ___ Message sent via/by

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #15, bug #40241 (project make): 3.8x deadlocks with -jN. As for paths, it's a complex issue. We can't reliably use msys paths everywhere (and for many reasons, we don't want to use more msys paths) ___ Reply to this item

[bug #40344] Can't handle Windows path names longer than 259 characters

Follow-up Comment #3, bug #40344 (project make): It looks like it would be the case, as success: ../../../../../../this-is-a-long-path-component-0/this-is-a-long-filename.txt fails too, with the current path being the original long path. I don't think there's any SUBST or CD way out of this.

[bug #40344] Can't handle Windows path names longer than 259 characters

Follow-up Comment #2, bug #40344 (project make): Note that "../../../../../../this-is-a-long-path-component-0/this-is-a-long-path-component-1/this-is-a-long-path-component-2/this-is-a-long-path-component-3/this-is-a-long-path-component-4/this-is-a-long-path-component-5/this-is-a-long-filename.txt"

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #13, bug #40241 (project make): Err, I was not looking at the right thing. It *is* bash not handling quotes properly: CreateProcess(C:mozilla-buildmsysbinsh.exe,C:/mozilla-build/msys/bin/sh.exe -c "c:/full/path/to/python.exe foo.py "a" b d",...)

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #12, bug #40241 (project make): Ah no, I'm hitting it again without BATCH_MODE_ONLY_SHELL. Here is a small testcase: $ cat > foo.py < Makefile ___ Message sent via/by Savannah http://savannah

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #11, bug #40241 (project make): Why not msys make? First, because i haven't found an msys make 4.0 build, and using msys make has its own quirks that are best avoided entirely. Why "/usr/bin/touch"? Well, it's not actually /usr/bin/touch, it's mostly /usr/bin/install or others,

[bug #40322] Interrupting a build with CTRL-C doesn't kill subprocesses

Follow-up Comment #5, bug #40322 (project make): As a matter of fact, we do have an intermediate process for those commands. I'll double check what's actually happening. ___ Reply to this item at: _

[bug #40344] Can't handle Windows long path names

URL: Summary: Can't handle Windows long path names Project: make Submitted by: glandium Submitted on: Tue 22 Oct 2013 04:49:10 AM GMT Severity: 3 - Normal Item Group: Bug

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #9, bug #40241 (project make): I'm using a msys bash shell, and i'm having problems with it unless I set BATCH_MODE_ONLY_SHELL. AFAICT, the patch I attached makes things use BATCH_MODE_ONLY_SHELL as I'd expect, so it works for me. I don't know why you don't want to hook at that

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #7, bug #40241 (project make): Without testing this patch I know I'll probably have trouble with it, as $SHELL doesn't handle quotes right and I'm setting BATCH_MODE_ONLY_SHELL, which your patch ignores for those. ___ Repl

[bug #40322] Interrupting a build with CTRL-C doesn't kill subprocesses

Follow-up Comment #3, bug #40322 (project make): So it looks like from observing what happens, that subprocesses do get killed (although i haven't looked at what happens in a debugger), but they do so gently. Make doesn't wait for the process to actually be dead. Which has several interesting side

[bug #40322] Interrupting a build with CTRL-C doesn't kill subprocesses

Follow-up Comment #2, bug #40322 (project make): The typical case where this happens is when link.exe is running to link xul.dll in a Firefox build. I'll check at some other random places. I'll also check what happens with the commands.c code in a debugger. ___

[bug #40322] Interrupting a build with CTRL-C doesn't kill subprocesses

URL: Summary: Interrupting a build with CTRL-C doesn't kill subprocesses Project: make Submitted by: glandium Submitted on: Mon 21 Oct 2013 12:28:18 AM GMT Severity: 3 - Normal

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #4, bug #40241 (project make): Besides the fact that your patch would leak the strdup'ed string, it doesn't work: $ ./Release/make_msvc.net2003.exe -f test.mk --trace test.mk:2: target 'foo' does not exist echo foo foo /usr/bin/touch foo /usr/bin/sh: (/w foo: No such file or dir

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #2, bug #40241 (project make): Something like: foo: /usr/bin/touch $@ fails because /usr/bin/touch doesn't exist in the filesystem (so, to answer your question, the former). ___ Reply to this item at:

[bug #40241] CreateProcess failure with unixy paths

URL: Summary: CreateProcess failure with unixy paths Project: make Submitted by: glandium Submitted on: Fri 11 Oct 2013 11:54:37 AM GMT Severity: 3 - Normal Item Group: E

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #1, bug #40227 (project make): The issue addressed by the second patch also manifests itself when using $(error) and $(warning), which don't print a message most of the time. ___ Reply to this item at: