[bug #42833] Prunes targets with pattern rules for no obvious reason
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 Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 4.0 Operating System: POSIX-Based Fixed Release: None Triage Status: None ___ Details: With the attached reduced testcase, running make -f test.mk recurse_compile doesn't yield all the possible values. It skips modules/libbz2/src/target. modules/libmar/src/target, toolkit/crashreporter/google-breakpad/src/common/linux/target and toolkit/crashreporter/google-breakpad/src/common/target. However, if you run make -f test.mk toolkit/library/gtest/target, which is one of the dependencies of the recurse_compile target, the toolkit/crashreporter/* ones are there, as expected from the dependencies. make -d tells they are pruned, and I see no obvious reason why, b ut maybe I'm wrong. When not using pattern rules, it works appropriately. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42833 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?42833 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 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 another one: $ cat EOF foo.mk default: c:/path/to/python.exe -c 'import sys; sys.argv[1:]' a b c EOF $ make -f foo.mk c:/path/to/python.exe -c 'import sys; sys.argv[1:]' a b c ['a b', 'c'] And that (obviously) doesn't need make to fail: (in a cmd.exe shell): c:/path/to/sh.exe -c c:/path/to/python.exe -c 'import sys; sys.argv[1:]' \a\ b c ['a b', 'c'] (yes, this is how make quotes it, and the quoting is correct) If you get the same result from the command line, then how is this a problem with what Make does? What am I missing? The point is, batch shell mode only flag is advertized in config.h as being the workaround for the broken sh -c. I'd like that workaround to be available at runtime instead of build time. $ mkdir foo $ echo foo foo/bar $ cat EOF foo.mk default: grep foo foo\\bar grep foo foo\\bar $ make -f foo.mk grep foo foo\\bar foo grep foo foo\\bar /usr/bin/sh: foobar: No such file or directory If you use forward slashes, do you see any problems in this case? Obviously, no. But again, this is not a path problem: $ cat EOF foo.mk default: echo foo foo\\bar echo foo foo\\bar EOF $ make -f foo.mk echo foo foo\\bar foo foo\bar echo foo foo\\bar foo foobar $ msysmake -f foo.mk echo foo foo\\bar foo foo\bar echo foo foo\\bar foo foo\bar That's what I said earlier: if you want Posix compatibility with backslash characters when your shell is MSYS Bash, you need to use the MSYS Make. The native build of Make doesn't treat backslashes as merely escape characters, it also treats them as directory separators. Obviously, that heuristic fails in this case, but the native Make is not supposed to deal with such cases. The native build of make doesn't end up treating backslashes equally depending on whether the command line happens to be nice enough for it to call CreateProcess directly or not. While it makes /some/ technical sense that it is this way, it makes *no* sense from a user perspective. Add to that the fact that both direct CreateProcess and batch shell mode have the same behaviour while sh -c doesn't. And now that i look at it, it *is* another sh -c bug. sigh. I'd be all for detecting if the shell used is win32 native or not, but at least, a user-runtime-togglable workaround for that would be better. So we're back to square one. How about that first patch of mine? Mike ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 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, even on Windows. Actually, with msys sh, it works. But Make doesn't know about that. When it works with a Unixy shell, it expects Posix file-name semantics. But the thing is there is still inconsistency in how things end up being invoked whether - make calls them directly - make uses sh -c - make uses sh script.sh That's barely a posix file-name semantics issue. In fact, for all purposes, make doesn't even need to know they are file names. The most bothering part is the inconsistency, not the fact that it considers them as file names or not. On Wed, Feb 05, 2014 at 05:44:18PM +0200, Eli Zaretskii wrote: Date: Wed, 5 Feb 2014 16:33:47 +0900 From: Mike Hommey m...@glandium.org Cc: psm...@gnu.org, bo...@kolpackov.net, bug-make@gnu.org 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 forward slashes, including in redirection. I didn't write that makefile, and that makefile is just a pile of awful things, not to say worse, and it does rely on the paths using backslashes for many different reasons. I tried switching to forward slashes, but many pieces broke as a result. The fact that I can get that makefile to work with batch shell mode is kind of a deliverance: i don't have to touch that pile of garbage. I see, thanks for explaining this. However, now I wonder why would it make sense to have this solved in upstream Make. Your use case sounds rather singular, so it could be solved by modifying your own copy of Make, right? I can see my unusual case as being a problem for other people too. It's always better if you can rely on unmodified tools to get things working. That's why I'd be totally fine with the first patch I attached, which adds the fake target to enable the workaround at runtime instead of buildtime. (And I wrote that patch because I don't want the horror show to propagate unwillingly and have other makefiles silently depend on paths with backslashes) Mike ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 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 - make calls them directly - make uses sh -c - make uses sh script.sh When the shell is a Unixy one, only the first 2 methods are used, and they are used exactly like on Posix platforms. Except when make is built with BATCH_MODE_SHELL_ONLY. Which is needed when sh -c fucks up with double quotes. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 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 - make calls them directly - make uses sh -c - make uses sh script.sh When the shell is a Unixy one, only the first 2 methods are used, and they are used exactly like on Posix platforms. Except when make is built with BATCH_MODE_SHELL_ONLY. Which is needed when sh -c fucks up with double quotes. And, more importantly, it's the first two that don't work the same way: $ mkdir foo $ echo foo foo/bar $ cat EOF foo.mk default: grep foo foo\\bar grep foo foo\\bar $ make -f foo.mk grep foo foo\\bar foo grep foo foo\\bar /usr/bin/sh: foobar: No such file or directory ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 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: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 - make calls them directly - make uses sh -c - make uses sh script.sh When the shell is a Unixy one, only the first 2 methods are used, and they are used exactly like on Posix platforms. Except when make is built with BATCH_MODE_SHELL_ONLY. Indeed, that's what that compile time option is for. But if that option messes up Make (does it?), we probably should delete it. Which is needed when sh -c fucks up with double quotes. I asked for test cases where this happens. Does this happen only when backslashes are used in file names? If so, I don't think that matters, since backslashes aren't supposed to be used in file names when a Unixy shell is used. I gave multiple examples already. It doesn't require backslashes to be a problem. Here's another one: $ cat EOF foo.mk default: c:/path/to/python.exe -c 'import sys; sys.argv[1:]' a b c EOF $ make -f foo.mk c:/path/to/python.exe -c 'import sys; sys.argv[1:]' a b c ['a b', 'c'] And that (obviously) doesn't need make to fail: (in a cmd.exe shell): c:/path/to/sh.exe -c c:/path/to/python.exe -c 'import sys; sys.argv[1:]' \a\ b c ['a b', 'c'] (yes, this is how make quotes it, and the quoting is correct) On Thu, Feb 06, 2014 at 07:45:53AM +0200, Eli Zaretskii wrote: Date: Thu, 6 Feb 2014 06:31:15 +0900 From: Mike Hommey m...@glandium.org Cc: psm...@gnu.org, bug-make@gnu.org, bo...@kolpackov.net Except when make is built with BATCH_MODE_SHELL_ONLY. Which is needed when sh -c fucks up with double quotes. And, more importantly, it's the first two that don't work the same way: $ mkdir foo $ echo foo foo/bar $ cat EOF foo.mk default: grep foo foo\\bar grep foo foo\\bar $ make -f foo.mk grep foo foo\\bar foo grep foo foo\\bar /usr/bin/sh: foobar: No such file or directory If you use forward slashes, do you see any problems in this case? Obviously, no. But again, this is not a path problem: $ cat EOF foo.mk default: echo foo foo\\bar echo foo foo\\bar EOF $ make -f foo.mk echo foo foo\\bar foo foo\bar echo foo foo\\bar foo foobar $ msysmake -f foo.mk echo foo foo\\bar foo foo\bar echo foo foo\\bar foo foo\bar Mike ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 EOF foo.mk foo: grep foo foo\\bar EOF (Note the is just there to trigger sh -c) This executes sh -c grep foo foo\\bar, which fails with: /usr/bin/sh: foobar: No such file or directory But in batch mode shell, this executes sh maken.sh with a content of grep foo foo\\bar and that fails with: maken.sh: line 1: foo\bar: No such file or directory (Note how in one case the backslash is eaten and not in the other case) 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 forward slashes, including in redirection. I agree about using backslashes as directory separators, that obviously cannot work in /bin/sh, even on Windows. Actually, with msys sh, it works. It just didn't work in my case because i didn't have a foo directory with a bar file in it. If i do create them, those commands work as expected (except the rule doesn't run because foo exists, so i need to rename it or make it phony) Mike ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 forward slashes, including in redirection. I didn't write that makefile, and that makefile is just a pile of awful things, not to say worse, and it does rely on the paths using backslashes for many different reasons. I tried switching to forward slashes, but many pieces broke as a result. The fact that I can get that makefile to work with batch shell mode is kind of a deliverance: i don't have to touch that pile of garbage. Mike ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 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, is whether we can find a way to know, without any hints from the user, whether a given command line will work properly for /bin/sh -c in Windows, or if it needs to use a batch file. Mike, could you please post some details about your use case(s) that required this? I'm not sure why would quotes not work with a Unixy shell. Perhaps this is once again something specific to the MSYS conversion of file names? I'm not sure why it happens, but here's how it manifests: $ cat EOF foo.mk foo: $(LS) c:\\Program Files EOF $ make -f foo.mk LS=$(which ls) C:/mozilla-build/msys/bin/ls.exe c:\\Program Files C:/mozilla-build/msys/bin/ls.exe: c:\Program: No such file or directory C:/mozilla-build/msys/bin/ls.exe: Files: No such file or directory foo.mk:2: recipe for target 'foo' failed make: *** [foo] Error 2 This happens for various absolute-path versions of LS, but not when LS=ls. This is something I mentioned in bug 40241 comment 12 and 13. 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 -c) This executes sh -c grep foo foo\\bar, which fails with: /usr/bin/sh: foobar: No such file or directory But in batch mode shell, this executes sh maken.sh with a content of grep foo foo\\bar and that fails with: maken.sh: line 1: foo\bar: No such file or directory (Note how in one case the backslash is eaten and not in the other case) When is not there and make executes grep directly, it fails with: grep: foo\bar: No such file or directory So there is a lack of consistency in how backslashes are treated when make uses sh -c or not. Note the second patch to bug 41246 solves the first issue but not the second. The first patch, with .BATCH_MODE_SHELL added to the makefile fixes both issues. Mike ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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_MODE_SHELL to the problematic makefile. There are still issues with backslashes, which I suspect are due to bad escaping when running with sh -c. Or discrepancy between sh -c and batch mode which leads to that particular Makefile miraculously working in batch mode. I'll need to do more testing. (file #30424) ___ Additional Item Attachment: File name: diff Size:2 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?41246 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 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. This cannot be automatic, as we have deliberately made the double quotes not special for Windows shells. You mean cmd.exe? The patch only uses batch mode shell when there are double quotes *and* the shell is unixy (so, not cmd.exe) So please make this conditional on some Make option (sorry, I didn't yet have time to look at the patch). An option as command line argument, or as a special target as the original patch did? Mike ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?41246 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?41246 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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 mind doing this for me? can someone describe for me what BATCH_MODE_ONLY_SHELL does? Does is overlap with ONESHELL? In essence, this is like ONESHELL, except it writes the script to a file to then run sh thatfile instead of doing sh -c line1nline2nline3. This is useful because msys bash on windows doesn't handle double quotes properly when run with sh -c. I don't think non-Windows systems would need this as a feature. ___ Reply to this item at: http://savannah.gnu.org/bugs/?41246 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?41246 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?40322 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #40503] Shebang detection is flawed
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 Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: SCM Operating System: MS Windows Fixed Release: None Triage Status: None ___ Details: According to http://git.savannah.gnu.org/cgit/make.git/tree/w32/subproc/sub_proc.c?id=9d58570c77240fed53d1f88217877f8e778f4bb2#n622 shebang detection just uses the file base name and assumes whatever in $PATH has that name will work. Except that doesn't work when you deliberately use a path that is not in $PATH for the shebang. We're hitting this in the Firefox build system, where a script has a shebang pointing to a virtualenv python executable, and the script doesn't work with the system python. I think the shebang executable detection should use the same logic (or kind of) as the logic for recipes. Ironically, make fails to get the file base name when the path uses back slashes instead of forward slashes, which makes shebang with back slashes have a different behavior. ___ Reply to this item at: http://savannah.gnu.org/bugs/?40503 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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 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 does not happen if using python instead of c:/full/path/to/python.exe. ... which turns out to be a make bug when *not* using the shell, contrary to what i thought. It happens to be fixed by BATCH_MODE_ONLY_SHELL because it forces the use of a shell in most cases and unbreaks things. ___ Reply to this item at: http://savannah.gnu.org/bugs/?40241 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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,...) ___ Reply to this item at: http://savannah.gnu.org/bugs/?40241 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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 is actually 238 characters long. Is make prepending the full current directory path too? ___ Reply to this item at: http://savannah.gnu.org/bugs/?40344 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?40344 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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 at: http://savannah.gnu.org/bugs/?40241 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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 item at: http://savannah.gnu.org/bugs/?40241 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?40241 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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 level. How many people do you think will be using commands starting with a forward slash that actually point to existing paths on the current drive? ___ Reply to this item at: http://savannah.gnu.org/bugs/?40241 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #40344] Can't handle Windows long path names
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 Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 4.0 Operating System: MS Windows Fixed Release: None Triage Status: None ___ Details: (Reported by Vladimir Vukicevic on the mozilla bug tracker) make 4.0 can't handle long path names, which need some special magic under windows -- you need to use the unicode versions of the IO functions, and prepend paths with the \\?\ UNC prefix. (Note that also turns off automatic / - \ conversion.) So, \\?\C:\foo\bar\baz instead of C:/foo/bar/baz or similar. STR: $ cd c:/tmp # or wherever $ mkdir -p 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 $ cd !$ $ echo hello this-is-a-long-filename.txt $ cat Makefile EOF all: success success: ../../../../../../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 cp $ $@ EOF $ make make: *** No rule to make target '../../../../../../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', needed by 'success'. Stop. ___ Reply to this item at: http://savannah.gnu.org/bugs/?40344 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?40322 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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, and that's because that's what comes out of configure. Interestingly, I'm testing your patch with BATCH_MODE_ONLY_SHELL undefined, and so far, it builds fine, but I'm only half-way through. ___ Reply to this item at: http://savannah.gnu.org/bugs/?40241 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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 directory test.mk:2: recipe for target 'foo' failed make_msvc.net2003: *** [foo] Error 127 (test.mk is the same as in comment #2, but with an additional echo foo in the recipe) Note without the echo foo, the error message is borked: $ ./Release/make_msvc.net2003.exe -f test.mk --trace test.mk:2: target 'foo' does not exist /usr/bin/touch foo /usr/bin/sh: Ó.wÿ: No such file or directory test.mk:2: recipe for target 'foo' failed make_msvc.net2003: *** [foo] Error 127 Which suggests unintialized memory use or something alike. ___ Reply to this item at: http://savannah.gnu.org/bugs/?40241 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #40322] Interrupting a build with CTRL-C doesn't kill subprocesses
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 Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 4.0 Operating System: MS Windows Fixed Release: None Triage Status: None ___ Details: When interrupting a build with CTRL-C on a win32 build, whatever was run by make at the time keeps running. This prevents subsequent make runs to run properly, either because of file locking or because the still running commands may alter the build directory during the second build. Note this is not a problem new to 4.0, it happened with previous releases too, as I am told. ___ Reply to this item at: http://savannah.gnu.org/bugs/?40322 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?40322 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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 effects: - the process keeps running for a little while, and eventually dies - it stays alive longer than it takes for make to (try to) remove the target file (xul.dll in my case). This has different possible outcomes, one of which is make failing to remove the file with a permissions denied error, the other of which is make supposedly removing the file, but the file being there after link.exe is done. Seeing the code, it seems to me this could happen on unix as well with a process that has a long shutdown when receiving SIGTERM/SIGINT. ___ Reply to this item at: http://savannah.gnu.org/bugs/?40322 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
