[bug #41246] Allow to switch shell batch mode at runtime instead of build time
Follow-up Comment #5, bug #41246 (project make): I'm not sure I like the idea of this being a special target in this way. It's also possible that something like this COULD be used on UNIX systems; there are limits to the size of command lines that can be invoked. On newer systems like Linux that limit is pretty large (I think it's 16K or so on Linux) but it exists, and on other systems it's much less. There's long been requests for @-file support embedded in make although exactly what form that would take hasn't been defined clearly IIRC. Let me ask this: would it be possible to simply use the existing ONESHELL capability and just say that on Windows it writes the script to a file and invokes the shell on it? The downside of this is that ONESHELL actually behaves differently (although often this doesn't matter). Also, if the normal behavior doesn't handle something as basic as quoting properly, why is BATCH_MODE_ONLY_SHELL not the default? Is there a downside to it? Or alternatively, if we detect that the script has content that might be problematic (quotes) we could automatically use the batch mode. I guess I'd just prefer things to work right automatically, without recompiling make or adding new pseudo targets. Is there a reason this is tricky or difficult? ___ 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 #40790] --enable-load in make 4.0 should auto-disable itself when no dlopen found
Update of bug #40790 (project make): Status:None = Fixed Open/Closed:Open = Closed Operating System:None = POSIX-Based Fixed Release:None = SCM ___ Follow-up Comment #3: I fixed the variable name errors, but left the rest in. The message is only printed if BOTH (a) the load support is not available, AND (b) the user explicitly asked for it by adding --enable-load on the command line. In that case I think it's right to tell them that their specific request was not achievable. However, if you just run ./configure without explicit --enable-load and load support is not available, it won't print any notes about load support. ___ Reply to this item at: http://savannah.gnu.org/bugs/?40790 ___ 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 Sat, Jan 18, 2014 at 4:17 PM, Paul D. Smith invalid.nore...@gnu.org wrote: There are limits to the size of command lines that can be invoked. On newer systems like Linux that limit is pretty large (I think it's 16K or so on Linux) but it exists, and on other systems it's much less. It's actually quite a bit bigger than that. On RHEL6 (2.6.32 kernel), getconf ARG_MAX reports 2621440. This, minus the size of the current environment, is the number of bytes available for command lines. It's conceivable that bash imposes its own limit due to fixed buffer sizes; I haven't checked. David ___ 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 #8, bug #41246 (project make): I understood that difference; that's why I said The downside of this is that ONESHELL actually behaves differently. However often this doesn't matter so much, particularly on Windows where the rules about what operations impact the parent's environment are not so strict as on POSIX systems (IIRC). I was wondering if it was close enough to be acceptable. In any event, I'd really prefer this be made to just work without special compile options or pseudo targets needed. Is there a reason why that's not feasible? ___ 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 #9, bug #41246 (project make): Also we do sometimes see people complaining about this, where they can't invoke commands because the command line is too long. There are various tricks out there for chunking make variable values containing lots and lots of words into smaller groupings. It has to be done in make itself, obviously. However, I will admit it's been a while since I've noticed a complaint about this. Either people have gotten used to it or it's become less of a problem. ___ 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 #41273] wildcard function does not return newly created file
URL: http://savannah.gnu.org/bugs/?41273 Summary: wildcard function does not return newly created file Project: make Submitted by: None Submitted on: Sun 19 Jan 2014 04:12:03 AM UTC Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 3.81 Operating System: MS Windows Fixed Release: None Triage Status: None ___ Details: Using a simple makefile under Windows 7, it became apparent that the wildcard function does not reflect the existence of a library created when the first object was added to it. This is make 3.81, as downloaded from gnuwin32: GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-pc-mingw32 C:\Users\admin\dev\lib\ll The attached listing shows both the GNUmakefile, and the resulting output showing that $(wildcard ll.lib) does not recognize the existence of the library after it was created. However, my workaround $(mywildcard) gives the correct results one would expect from the wildcard function. This is consistent with the mention that a cache is probably used to avoid actually checking the filesystem and can therefore cause inconsistent results. Curiously, repeated tests showed that occasionally the wildcard function would begin showing the existence of the library file in the middle of building and adding the eight object files. But usually it would not recognize the file until the make was run a second time. Thank you, Harry Clauson ___ Reply to this item at: http://savannah.gnu.org/bugs/?41273 ___ 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 #41273] wildcard function does not return newly created file
Additional Item Attachment, bug #41273 (project make): File name: wildcard.txt Size:6 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?41273 ___ 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
