[bug #65759] handling of "-" and "--" on command line

Follow-up Comment #4, bug #65759 (group make): (original poster) Understood about --. WRT -, I don't think it should be an error, I think it should be treated as a filename as Dmitry says. IMHO the interesting question is: given that - should be treated as a valid filename, should it be required

[bug #65759] handling of "-" and "--" on command line

Triage Status: None ___ Follow-up Comments: --- Date: Sun 19 May 2024 02:35:54 PM UTC By: Anonymous I don't know whether this is considered a bug per se but it's pretty confusing. Consider the

[bug #45763] Split args along MAX_ARG_STRLEN for linux/posix

Follow-up Comment #4, bug #45763 (group make): Hello, I also encountered such an issue that make-4.3 reported "Argument list too long". May I know whether this is fixed on master branch? ___ Reply to this item at:

[bug #65596] Test for let function not available in .FEATURES

: None ___ Follow-up Comments: --- Date: Mon 15 Apr 2024 07:08:37 PM UTC By: Anonymous THE .FEATURES variable does not include a value for the "le

[bug #65510] INSTALL file not present

: None ___ Follow-up Comments: --- Date: Sat 23 Mar 2024 01:21:18 PM UTC By: Anonymous README.in references an INSTALL file, but neither the source tarballs or the git repository contain the file. reference:

[bug #41781] Provide a fast fail path when a target is compromized during a parallel build

Follow-up Comment #3, bug #41781 (group make): In Gentoo, we always do clean builds, so the issue of resumption / corrupt rules wouldn't be a problem for us. I wouldn't expect this functionality to be on by default if made available, but having the option would be great. The main motivation for

[bug #65383] copy command does not work on Windows

: None ___ Follow-up Comments: --- Date: Wed 28 Feb 2024 02:14:25 PM UTC By: Anonymous copy file command will be error on both Powershell, CMD and Powershell Core This teak fixes it, should we i

[bug #65276] SECONDEXPANSION doesn't work correctly with escaped spaces

Status: None ___ Follow-up Comments: --- Date: Thu 08 Feb 2024 06:44:26 PM UTC By: Anonymous I attached a Makefile and t.cpp. Put these into a directory which has a space in its name. Ru

[bug #65268] Reset O_APPEND mode for stdout and stderr

: None ___ Follow-up Comments: --- Date: Tue 06 Feb 2024 07:51:46 PM UTC By: Anonymous The commit introducing the bug is https://git.savannah.gnu.org/cgit/make.git/comm

[bug #64924] Missing Close Parenthesis

: None ___ Follow-up Comments: --- Date: Thu 23 Nov 2023 10:14:03 PM UTC By: Anonymous This page of documentation (https://www.gnu.org/software/make/manual/html_node/Goals.html) contains the following: s

[bug #64650] LD is not reported as an IMPLICIT VARIABLE

: None ___ Follow-up Comments: --- Date: Sun 10 Sep 2023 01:23:18 PM UTC By: Anonymous See https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html. There is no

[bug #64472] $(CP) is an empty string

Follow-up Comment #1, bug #64472 (project make): https://www.gnu.org/software/make/manual/html_node/Utilities-in-Makefiles.html says that $(INSTALL) should be used instead of directly invoking install(1) but says nothing about $(CP). Indeed, it contrasts cp with install, saying that cp is OK to

[bug #64472] $(CP) is an empty string

: None ___ Follow-up Comments: --- Date: Wed 26 Jul 2023 02:43:06 AM UTC By: Anonymous The documentation section [https://www.gnu.org/software/make/manual/make.html#Utilities-in-Makefiles 16.2 Utilities in Mak

[bug #64402] error parsing functions in braces inside ifeq, ifneq

: None ___ Follow-up Comments: --- Date: Mon 10 Jul 2023 11:40:55 AM UTC By: Anonymous Per the GNU make manual, function call syntax is either $(function arguments) # paren

[bug #64129] Using $(filter ...) on a variable with a large number of words causes seg fault

: None Triage Status: None ___ Follow-up Comments: --- Date: Sun 30 Apr 2023 07:46:59 PM UTC By: Anonymous If I try to use the filter function on a variable that consists of a

[bug #64085] -e passed to shell in POSIX mode with -i or .IGNORE

Status: None ___ Follow-up Comments: --- Date: Fri 21 Apr 2023 12:55:10 PM UTC By: Anonymous Bug #63667 was closed after Make was changed to not pass -e to the shell if a command was pr

[bug #64002] Improve MAKEFILE_LIST with include

: None ___ Follow-up Comments: --- Date: Wed 05 Apr 2023 05:00:15 PM UTC By: Anonymous The "include " statement is a way to extend make and re-use existing code and make less copy paste errors

[bug #63984] Error 2133

: None ___ Follow-up Comments: --- Date: Fri 31 Mar 2023 01:26:38 PM UTC By: Anonymous ___ File Attachments: --

[bug #63981] suppress "-jN forced in submake" warning with -j1

age Status: None ___ Follow-up Comments: --- Date: Thu 30 Mar 2023 04:03:07 PM UTC By: Anonymous In a recursive make model there may be a subdirectory which isn't parallel-safe.

[bug #63852] Two test failure running the test suite as root

Additional Item Attachment, bug #63852 (project make): File name: makeerror-4.4.1-x86_64-pc-linux-gnu-4quo.tar.gz Size:46 KB ___ Reply

[bug #63650] Performance regression with EXPORT_ALL_VARIABLES enabled

Follow-up Comment #7, bug #63650 (project make): I don't think it is reasonable to cache environment. The number of operations needed for a single expansion is a very fast growing sequence. So if it will help with e.g. n=5, n=6 will still take a long time to compute. Maybe just show a warning

[bug #63650] Performance regression with EXPORT_ALL_VARIABLES enabled

Follow-up Comment #1, bug #63650 (project make): Update: reproduces when building from git. Commit sha f51fc130, message: [SV 63638] Fix processing PATH on MS-Windows ___ Reply to this item at:

[bug #63650] Performance regression with EXPORT_ALL_VARIABLES enabled

Status: None ___ Follow-up Comments: --- Date: Fri 13 Jan 2023 12:33:13 PM UTC By: Anonymous On fresh Arch Linux make takes 3.5s for the following makefile. .EXPORT_ALL_VARIABLES

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

Follow-up Comment #12, bug #63638 (project make): Okay I'll do that as soon as I can. Thanks again for your help with the PATH issue. Best regards. ___ Reply to this item at:

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

Follow-up Comment #10, bug #63638 (project make): Indeed, I followed your instructions and I can confirm that the PATH bug is now gone. Thank you kindly. However, as you suspected, my real application still does not build successfully... It seems to be an unrelated problem, though. My parallel

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

Follow-up Comment #8, bug #63638 (project make): I downloaded the Make binaries through MSYS2 with: pacman -S mingw-w64-x86_64-make Yes, I have a MinGW development environment installed and I can compile C programs. ___ Reply to this

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

Follow-up Comment #6, bug #63638 (project make): Eli, Paul, thanks a lot for finding the cause of the problem so quickly! I am just an end user of make, though, and to be quite honest I don't know how to apply your patch, rebuild make, and test my real-life Makefile. (I'm really sorry about

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

Follow-up Comment #2, bug #63638 (project make): Thank you very much for your quick response, Paul. Good to know that you can reproduce this behavior. I'll switch back to 4.3 for now. Thanks again for your time, Best regards ___ Reply

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

Additional Item Attachment, bug #63638 (project make): File name: Makefile Size:0 KB ___ Reply to this item at:

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

: None Triage Status: None ___ Follow-up Comments: --- Date: Mon 09 Jan 2023 10:01:07 PM UTC By: Anonymous Consider the following minimal example: # --- # show the c

[bug #63621] Enhancement request - new built in variables

: None ___ Follow-up Comments: --- Date: Wed 04 Jan 2023 03:56:14 PM UTC By: Anonymous See discussion in https://stackoverflow.com/questions/74707248/using-call-in-a-makefile-

[bug #63552] includes specified with -I ignored when -C is also used, since 4.4

Triage Status: None ___ Follow-up Comments: --- Date: Tue 20 Dec 2022 11:14:25 AM UTC By: Anonymous There's a regression in v4.4 where if you invoke make with both -C and -I parameters, the i

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #6, bug #63516 (project make): [comment #5 comment #5:] > Thanks for the patch. > > I have three comments: > > (1) The test under "WINDOWS32" should allow a backslash after the colon as well as a forward slash. Sounds right. > > (2) Do we want Make to consider

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #4, bug #63516 (project make): I've attached my fix in case it's helpful. Also attached is a small fix to `bootstrap.bat` that I had to make to get it to build with `tcc`. (file #54105, file #54106) ___ Additional Item

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #2, bug #63516 (project make): Line 376 in `src/read.c` may be the culprit: if (ebuf.fp == NULL && deps->error == ENOENT && (flags & RM_INCLUDED) && *filename != '/' && include_directories) Looks like it's trying to determine whether the path is absolute in a way

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #1, bug #63516 (project make): `make` was installed with `scoop`. ___ Reply to this item at: ___ Message sent via Savannah

[bug #63516] `include` of absolute path prepends path with `./`

: None ___ Follow-up Comments: --- Date: Mon 12 Dec 2022 10:17:30 PM UTC By: Anonymous When trying to `include` a file with an absolute path (including drive path), the include directive pr

[bug #63315] Test failures with 4.4 on OpenBSD

Follow-up Comment #8, bug #63315 (project make): Me too, on OmniOS. Presumably Linux will map the shared object back into the same address as before, or has that just been luck? It's definitely not the case on all operating systems. Please consider changing the title of this bug so it's easier

[bug #63315] Test failures with 4.4 on OpenBSD

Follow-up Comment #7, bug #63315 (project make): I also hit this on illumos, and just reached the same conclusion - that the memory containing the function name in the hash table entry becomes unmapped when testapi.so is unloaded and loaded again. I'll apply the patch, thanks!

[bug #63352] nested conditional wrongly reports extraneous endif

: None ___ Follow-up Comments: --- Date: Sat 12 Nov 2022 05:04:07 PM UTC By: Anonymous The attached makefile causes GNU make 4.3 to produce the following erroneous

[bug #63347] make 4.4 change in behavior for sub-make invoked via $(shell)

Triage Status: None ___ Follow-up Comments: --- Date: Fri 11 Nov 2022 08:21:14 PM UTC By: Anonymous It appears that make 4.3 never passed environment down to sub-make if invoked via shell

[bug #63330] readdir() error in 4.4 on Solaris 8

Follow-up Comment #11, bug #63330 (project make): I was working from a git checkout and it appears that it somehow got into a strange state. A build of a fresh download of the 4.4 tarball is fine. My apologies for the confusion, this can be closed.

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

Follow-up Comment #15, bug #63307 (project make): Whether that's "equally likely" is something we are probably going to disagree over, especially in the case where output (or potentially error) is piped to another process, but not worth getting into a discussion about. Suffice to say, it is

[bug #63330] readdir() error in 4.4 on Solaris 8

Follow-up Comment #8, bug #63330 (project make): Just checked and this also affects Solaris 10. The issue looks identical, let me know if you want details from that system. ___ Reply to this item at:

[bug #63330] readdir() error in 4.4 on Solaris 8

Follow-up Comment #7, bug #63330 (project make): Oh and yes, 4.3 works just fine on NFS mounts. It's what I've been using to build 4.4. The NFS mount is definitely over 4GB but this is the first time I've run into issues with that. ___

[bug #63330] readdir() error in 4.4 on Solaris 8

Follow-up Comment #6, bug #63330 (project make): I definitely don't expect everything to work perfectly on a system this old, and if it does turn out to be a Solaris bug I'll certainly find a way to deal with it locally. That being said I find that compiling on these older systems sometimes

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

Follow-up Comment #13, bug #63307 (project make): When SIGPIPE is set to the default action, then yes, writing to a closed pipe is expected to get make to die abnormally. That's how SIGPIPE is designed to work. :) This is different from a regular failure to write to stdout. There is little

[bug #63330] readdir() error in 4.4 on Solaris 8

Follow-up Comment #4, bug #63330 (project make): It looks like this is somehow related to NFS. I was running the newly-generated make in the root of the source tree, and on an NFS mounted directory it fails immediately. If I copy the tree to a local directory I have no problems.

[bug #63330] readdir() error in 4.4 on Solaris 8

: None ___ Follow-up Comments: --- Date: Mon 07 Nov 2022 03:37:45 PM UTC By: Anonymous I'm getting an error in readdir() on Solaris 8 with 4.4 compiled with both gcc and Sun Studio 11: make: *** IN

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

Follow-up Comment #8, bug #63307 (project make): There may be an even simpler solution than that. There was never any need to ignore SIGPIPE, we just need to make sure temporary files are cleaned up if we get SIGPIPE, it's okay and expected if make dies after that cleanup. There is already a

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

Follow-up Comment #7, bug #63307 (project make): > Other reasons are the desire to avoid complexity in make. I agree with the desire to avoid complexity, but preserving an ignored SIGPIPE on top of your patch needs no more than: if (bsd_signal (SIGPIPE, handle_sigpipe) == SIG_IGN)

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

Follow-up Comment #4, bug #63307 (project make): Nice idea to just have a signal handler that does nothing. If SIGIGN was ignored before make was started though, it should remain ignored, even for make's children, see also in

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

Follow-up Comment #5, bug #63307 (project make): That previous comment was meant to read SIGPIPE, not SIGIGN, of course :) ___ Reply to this item at:

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

Follow-up Comment #1, bug #63307 (project make): Can confirm the patch posted to the mailing list, , works for me to fix this. Thanks for the prompt response. ___ Reply to

[bug #63248] Ignore sigpipe.

Follow-up Comment #5, bug #63248 (project make): Thanks, I have submitted #63307 for it. ___ Reply to this item at: ___ Message sent via Savannah

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

: None ___ Follow-up Comments: --- Date: Wed 02 Nov 2022 03:12:02 PM UTC By: Anonymous Test case: $ cat Makefile all: (sleep 1; echo foo; echo bar >&2) | : $ make-4.3 (slee

[bug #63248] Ignore sigpipe.

Follow-up Comment #3, bug #63248 (project make): Hi, this change does not just mean make ignores SIGPIPE, it also means everything spawned by make ignores SIGPIPE. Is this intentional? I am seeing a failure in another package as a result of this after updating to make 4.4 and do not know whether

[bug #63241] implement "exit" in makefile parsing

age Status: None ___ Follow-up Comments: --- Date: Wed 19 Oct 2022 04:43:52 PM UTC By: Anonymous I’ll start this by making an analogy with scripting languages. A Python script might have lo

[bug #63187] make: *** invalid shuffle mode: Invalid value: '0r'. Stop.

Triage Status: None ___ Follow-up Comments: --- Date: Sun 09 Oct 2022 08:53:01 AM UTC By: Anonymous I tried enabling random shuffling on make master(commi

[bug #63172] Using --just-print, -n on a target that uses a multiline macro function will print as a single line

Fixed Release: None Triage Status: None ___ Follow-up Comments: --- Date: Thu 06 Oct 2022 04:49:00 PM UTC By: Anonymous Hi. I noticed that if I have the following Makefile ```

[bug #63070] posix_spawn fails to run a child process.

Follow-up Comment #2, bug #63070 (project make): No, if posix_spawn() returns zero then then errno's value is unspecified and any checks against it are invalid resulting in false positives.If some versions of glibc have posix_spawn() return 0 when they did not create the target process then the

[bug #62929] Normalize foo/./bar

Follow-up Comment #12, bug #62929 (project make): Couldn't the 2nd and 3rd sentences be simplified as: The default goal is the _first_ target of the first rule in the first makefile. ___ Reply to this item at:

[bug #62936] Confusing description of chained rules in the manual

Status: None ___ Follow-up Comments: --- Date: Mon 22 Aug 2022 09:05:20 AM UTC By: Anonymous Trying to understand a bug in my Makefile, I consulted the manual section on chained rules

[bug #62595] Add ability to read .env files into make and

Follow-up Comment #6, bug #62595 (project make): > ⚠ External Email > > Follow-up Comment #4, bug #62595 (project make): > > No, no, that's not something one should expect from a .env file. > > I said that _some_ dotenv parsers take it a step further to do all that fancy >

[bug #62441] Recursive make & PHONY = targets being rebuilt [feature reques]

URL: Summary: Recursive make & PHONY = targets being rebuilt [feature reques] Project: make Submitted by: None Submitted on: Wed 11 May 2022 03:48:10 PM UTC Severity: 3 - Normal

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

URL: Summary: patsubst not working in prerequisites under .SECONDEXPANSION Project: make Submitted by: None Submitted on: Thu 10 Mar 2022 10:06:34 AM UTC Severity: 3 - Normal

[bug #61955] Remade Makefiles & Phony Targets

URL: Summary: Remade Makefiles & Phony Targets Project: make Submitted by: None Submitted on: Fri 28 Jan 2022 08:56:59 PM UTC Severity: 3 - Normal Item Group: Bug

[bug #61621] unshare -Upf no longer works on make unless --disable-posix-spawn is given

URL: Summary: unshare -Upf no longer works on make unless --disable-posix-spawn is given Project: make Submitted by: None Submitted on: Sun 05 Dec 2021 01:51:55 AM UTC Severity: 3 -

[bug #61594] suggest new $(hash ...) function

Follow-up Comment #1, bug #61594 (project make): These are all good and useful points, thanks. However, some counter-arguments: I tried to be careful to distinguish "cryptographic" from "low-collision-rate-hash" in the original description because I absolutely do not want to "introduce

[bug #61594] suggest new $(hash ...) function

URL: Summary: suggest new $(hash ...) function Project: make Submitted by: None Submitted on: Wed 01 Dec 2021 04:36:41 AM UTC Severity: 3 - Normal Item Group:

[bug #61463] private does not suppress inheritance on exported target specific variables

URL: Summary: private does not suppress inheritance on exported target specific variables Project: make Submitted by: None Submitted on: Wed 10 Nov 2021 07:28:11 PM UTC Severity: 3 -

[bug #61321] Extend the Overview chapter

Additional Item Attachment, bug #61321 (project make): File name: 0001-Extend-the-Overview-chapter-in-the-documentation.patch Size:3 KB

[bug #61321] Extend the Overview chapter

URL: Summary: Extend the Overview chapter Project: make Submitted by: None Submitted on: Sat 09 Oct 2021 03:34:54 PM UTC Severity: 3 - Normal Item Group: Documentation

[bug #61309] Bad rule evaluation when SHELL variable contains environment variables

URL: Summary: Bad rule evaluation when SHELL variable contains environment variables Project: make Submitted by: None Submitted on: Fri 08 Oct 2021 09:59:57 AM UTC Severity: 3 -

[bug #17448] Function argument parsing inconsistent in treatment of whitespace

Follow-up Comment #1, bug #17448 (project make): I found a very annoying problem which seems related to this issue (and only apply to v >= 4.2 which includes function `file`): This one will read `filename`: $(file https://savannah.gnu.org/bugs/?17448>

[bug #61171] Unexpected warning "Circular test.mm <- test.mm.o dependency dropped."

URL: Summary: Unexpected warning "Circular test.mm <- test.mm.o dependency dropped." Project: make Submitted by: None Submitted on: Thu 16 Sep 2021 04:45:12 PM UTC Severity: 3 -

[bug #61154] (w32/sub_proc.c) make_command_line should also quote full_exec_path.

Follow-up Comment #1, bug #61154 (project make): The place where `make_command_line` copies `full_exec_path` without quoting it is http://git.savannah.gnu.org/cgit/make.git/tree/src/w32/subproc/sub_proc.c#n1339, not line 1360. ___ Reply to

[bug #61154] (w32/sub_proc.c) make_command_line should also quote full_exec_path.

URL: Summary: (w32/sub_proc.c) make_command_line should also quote full_exec_path. Project: make Submitted by: None Submitted on: Tue 14 Sep 2021 03:02:34 AM UTC Severity: 3 - Normal

[bug #60960] Fix/report race problem if having multiple "alias" for the same target

URL: Summary: Fix/report race problem if having multiple "alias" for the same target Project: make Submitted by: None Submitted on: Thu 22 Jul 2021 01:49:14 PM UTC Severity: 3 -

[bug #60435] Chained pattern rules with multiple targets not removing all intermediate files

URL: Summary: Chained pattern rules with multiple targets not removing all intermediate files Project: make Submitted by: None Submitted on: Thu 22 Apr 2021 02:00:49 AM UTC Severity:

[bug #60312] echo replaces double quote with backslash

Follow-up Comment #4, bug #60312 (project make): I do have it: $ which sh /usr/bin/sh but make seems to be calling echo.exe directly. Extracts from "strace make -f tm": 0 0 [main] echo (7896) ** 155 155 [main] echo (7896) Program

[bug #60312] echo replaces double quote with backslash

Follow-up Comment #2, bug #60312 (project make): Yes, you're right. I thought echo was an internal command. I investigated further and the culprit seems to be the POSIX emulation library, which does strange things trying to emulate shell globbing. Sorry for the inconvenience, please discard this

[bug #60312] echo replaces double quote with backslash

URL: Summary: echo replaces double quote with backslash Project: make Submitted by: None Submitted on: Tue 30 Mar 2021 08:22:32 PM UTC Severity: 3 - Normal Item Group:

[bug #60281] Directory in directory in $PATH shadows binaries in $PATH

URL: Summary: Directory in directory in $PATH shadows binaries in $PATH Project: make Submitted by: None Submitted on: Tue 23 Mar 2021 09:50:35 PM UTC Severity: 3 - Normal

[bug #60165] Multiple pattern rules with single rule

URL: Summary: Multiple pattern rules with single rule Project: make Submitted by: None Submitted on: Wed 03 Mar 2021 09:24:53 PM UTC Severity: 3 - Normal Item Group:

[bug #59956] Recipes inside conditionals can break the parser

URL: Summary: Recipes inside conditionals can break the parser Project: make Submitted by: None Submitted on: Wed 27 Jan 2021 08:29:00 PM UTC Severity: 3 - Normal Item

[bug #59881] Segmentation Fault through manipulated Makefile

URL: Summary: Segmentation Fault through manipulated Makefile Project: make Submitted by: None Submitted on: Fri 15 Jan 2021 01:18:53 PM UTC Severity: 3 - Normal Item

[bug #59762] make --touch produce local spurious empty files with out-of-tree Makefile strategy

URL: Summary: make --touch produce local spurious empty files with out-of-tree Makefile strategy Project: make Submitted by: None Submitted on: Thu 24 Dec 2020 03:43:44 PM UTC

[bug #59691] feature requests: something similiar to __LINE__ and __FILE__ in C

URL: Summary: feature requests: something similiar to __LINE__ and __FILE__ in C Project: make Submitted by: None Submitted on: Tue 15 Dec 2020 02:06:22 PM UTC Severity: 3 - Normal

[bug #59585] Make with output-sync prints 'fcntl(): Bad file descriptor' on MacOS when output is piped

URL: Summary: Make with output-sync prints 'fcntl(): Bad file descriptor' on MacOS when output is piped Project: make Submitted by: None Submitted on: Tue 01 Dec 2020 11:10:50 AM UTC

[bug #59584] ifeq with a space after the first open parenthesis

URL: Summary: ifeq with a space after the first open parenthesis Project: make Submitted by: None Submitted on: Tue 01 Dec 2020 03:55:44 AM UTC Severity: 3 - Normal

[bug #59467] --no-print-directory has no effect if command parsing complains about -j options

URL: Summary: --no-print-directory has no effect if command parsing complains about -j options Project: make Submitted by: None Submitted on: Mon 16 Nov 2020 07:46:31 PM UTC

[bug #59243] Overcomplicated example of automatic dependency configuration

URL: Summary: Overcomplicated example of automatic dependency configuration Project: make Submitted by: None Submitted on: Fri 09 Oct 2020 03:49:50 PM UTC Severity: 3 - Normal

[bug #59211] Add a commandline option to print the executed command with unexpanded variables

URL: Summary: Add a commandline option to print the executed command with unexpanded variables Project: make Submitted by: None Submitted on: Thu 01 Oct 2020 07:43:20 AM UTC

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #15, bug #59154 (project make): Also: I have great respect for the difficulty of getting stuff like this right. (I recently stared down the maw of commandline issues in response files in meson... https://github.com/mesonbuild/meson/pull/7245 ) so while I may have sounded glib,

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #14, bug #59154 (project make): [comment #10 comment #10:] > GNU makefiles will allow the following makefile: > > > define SOMECOMMAND > cd foo && echo one > cd foo && echo two > endef > > all: ; $(SOMECOMMAND) > > > to print both "one" and "two" when there is a

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #9, bug #59154 (project make): I don't think this would require Make to parse double quotes. My guess is it would mean passing along expanded variables to the shell without parsing the variable contents for newlines. If I have time, maybe I'll have a look at whether my guess

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #4, bug #59154 (project make): "Newlines in variable expansions are treated as real newlines in the rule." Well, yes, of course. What I didn't expect is for the command to be truncated at the first newline. The shell script BLAH="hi there" export BLAH echo "$BLAH" properly

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #7, bug #59154 (project make): If the string isn't quoted, the first newline would naturally signal a new command to the shell, wouldn't it? Got an example of a real-world Makefile that would break? ___ Reply to this

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #5, bug #59154 (project make): (To be precise, the line echo "${BLAH}" works in all the shells I've tested, and in BSD Make, but not GNU Make. If BSD Make can get this right, seems like gnu make should be able to, too.)

  1   2   3   4   5   6   7   >