[bug #59169] Add a --debug=why category for the -d/--debug option

URL: Summary: Add a --debug=why category for the -d/--debug option Project: make Submitted by: boyski Submitted on: Wed 23 Sep 2020 02:22:35 AM UTC Severity: 3 - Normal

[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, I

[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 subdirectory

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #13, bug #59154 (project make): Yes, I said: > when there is a subdirectory "foo" which is empty. Your subdirectory "foo" is not empty, it contains a sub-subdirectory "foo" :). Basically people use define/endef to create recipes which can span multiple lines, and they expect

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #12, bug #59154 (project make): [comment #10 comment #10:] > If the variable is passed to a single shell then it will print an error at the second "cd". Eh? martind@sirius:~/tmp/make-59154$ bash -c 'cd foo && echo one cd foo && echo two' one two martind@sirius:~/tmp/make-59154

INSTALL misdirection

I know the INSTALL file is missing from 4.3 so I can't check it directly, so while building a new copy of 4.3 from source I relied on the version from 4.2.1. It says: 1. `cd' to the directory containing the package's source code and type `./configure' to configure the package for your syste

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #11, bug #59154 (project make): [comment #9 comment #9:] > 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'l

[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 is

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #8, bug #59154 (project make): [comment #7 comment #7:] > 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? Nope. But that doesn't mean there isn't one. Th

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #10, bug #59154 (project make): I already explained below why it works the way it does... maybe my mic is not on? Am I on mute? I do that all the time on my video calls. BSD make doesn't support multiline variable definitions the way GNU make does, so it makes sense that they

[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 item

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #6, bug #59154 (project make): [comment #5 comment #5:] > (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.) This could break a t

[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.) ___