URL:
http://savannah.gnu.org/bugs/?42833
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
Additional Item Attachment, bug #42833 (project make):
File name: test.mkSize:18 KB
___
Reply to this item at:
http://savannah.gnu.org/bugs/?42833
___
Message sent
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 m...@glandium.org
Cc: psm...@gnu.org, bug-make@gnu.org, bo...@kolpackov.net
I gave multiple examples already. It doesn't require backslashes to be a
problem. Here's
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 m...@glandium.org
Cc: Eli Zaretskii e...@gnu.org, bug-make@gnu.org
I agree about using backslashes as directory separators, that obviously
cannot work in /bin/sh
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 m...@glandium.org
Cc: psm...@gnu.org, bug-make@gnu.org, bo...@kolpackov.net
But the thing is there is still inconsistency in how things end up being
invoked whether
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 m...@glandium.org
Cc: psm...@gnu.org, bug-make@gnu.org, bo...@kolpackov.net
But the thing
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 m...@glandium.org
Cc: psm...@gnu.org, bug-make@gnu.org, bo...@kolpackov.net
On Wed, Feb 05, 2014 at 11:10:11PM +0200, Eli Zaretskii wrote:
Date: Thu, 6 Feb 2014 05
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 EOF foo.mk
foo:
grep foo foo\\bar
EOF
(Note the is just there to trigger sh
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
On Sat, Feb 01, 2014 at 11:29:19AM +0200, Eli Zaretskii wrote:
From: Paul Smith psm...@gnu.org
Cc: Mike Hommey m...@glandium.org, mh+savan...@glandium.org,
bo...@kolpackov.net, bug-make@gnu.org
Date: Fri, 31 Jan 2014 10:59:13 -0500
My question, or _challenge_ if you like
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
On Fri, Jan 31, 2014 at 11:37:47AM +0200, Eli Zaretskii wrote:
Date: Fri, 31 Jan 2014 09:14:32 +
From: Mike Hommey invalid.nore...@gnu.org
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
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.
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:
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
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:
http://savannah.gnu.org/bugs/?41246
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.
___
URL:
http://savannah.gnu.org/bugs/?40503
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
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 EOF
import sys
print sys.argv
EOF
$ cat Makefile EOF
foo:
c:/full/path/to/python.exe foo.py a b c
EOF
$ make
[foo.py, a b, c]
This
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,...)
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
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.
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
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
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.
___
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
URL:
http://savannah.gnu.org/bugs/?40344
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
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:
http://savannah.gnu.org/bugs/?40322
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,
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
URL:
http://savannah.gnu.org/bugs/?40322
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
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.
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
33 matches
Mail list logo
