[bug #42270] Make needs to canonicalise paths

Follow-up Comment #2, bug #42270 (project make): The bug wasn't opened by someone looking to have symlinks resolved, but that's what will happen if you canonicalize paths. Applications must assume that symbolic links belong to the user and not expand them, unless somehow explicitly requested. Ap

[bug #10593] $(shell) doesn't honor export but this is undocumented?

Follow-up Comment #8, bug #10593 (project make): This solution works for me, thanks to $(shell var=val command arg ...) working fine: # put desired env vars into "shell_env" variable shell_exports := foo000=bar000 foo001=bar001 # interpolate variable as a prefix of shell command $

[bug #8297] Allow multiple targets to be built from a single explicit rule recipe invocation

Additional Item Attachment, bug #8297 (project make): File name: 0001-Implement-grouped-targets-in-ordinary-rules.patch Size:23 KB ___

[bug #8297] Allow multiple targets to be built from a single explicit rule recipe invocation

Follow-up Comment #9, bug #8297 (project make): Regarding the past discussion, this comment by Henning Makholm: https://lists.gnu.org/archive/html/make-alpha/2002-12/msg7.html provides an accurate synopsis of what I have also done. >From the GNU Make manual, I realized that the semantics is

[bug #8297] Allow multiple targets to be built from a single explicit rule recipe invocation

Additional Item Attachment, bug #8297 (project make): File name: 0001-Implement-grouped-targets-in-ordinary-rules.patch Size:20 KB ___

[bug #8297] Allow multiple targets to be built from a single explicit rule recipe invocation

Additional Item Attachment, bug #8297 (project make): File name: 0001-Implement-grouped-targets-in-ordinary-rules.patch Size:20 KB ___

[bug #8297] Allow multiple targets to be built from a single explicit rule recipe invocation

Follow-up Comment #8, bug #8297 (project make): The patch I uploaded just now is almost the same as what I posted to the mailing list, modulo fixing a memory leak (not freeing the also_make dep list built up in the register_files function). Paul Smith pointed to this bug and suggested the &: synt

[bug #8297] Allow multiple targets to be built from a single explicit rule recipe invocation

Additional Item Attachment, bug #8297 (project make): File name: 0001-Implement-grouped-targets-in-ordinary-rules.patch Size:10 KB ___

[bug #10593] $(shell) doesn't honor export but this is undocumented?

Follow-up Comment #5, bug #10593 (project make): Of course this creates a backward compatibility problem if it is fixed. It is a change to existing behavior. For any such change, we can contrive code which depends on the old behavior. For instance, when ISO C added // comments in 1999, it broke c

[bug #43757] Target-specific assigments influencing whether target considered intermediate.

Follow-up Comment #2, bug #43757 (project make): I must say I cannot agree with the analysis of the previous comment. A target listed in a target-specific variable assignment is, at best, *syntactically* a target, not semantically. Obviously, it cannot be semantically because the variable assign

[bug #43757] Target-specific assigments influencing whether target considered intermediate.

URL: Summary: Target-specific assigments influencing whether target considered intermediate. Project: make Submitted by: kkylheku Submitted on: Thu 04 Dec 2014 05:20:14 PM PST Severity

[bug #43432] Two flavors of variable: describe more aptly, in line with other languages.

URL: Summary: Two flavors of variable: describe more aptly, in line with other languages. Project: make Submitted by: kkylheku Submitted on: Fri 17 Oct 2014 11:50:57 AM PDT Severity: 3

[bug #27609] Stupid inference rule for yacc files can clobber C sources!

Follow-up Comment #11, bug #27609 (project make): I tried .SUFFIXES: but now make tried to build the program even though lex.yy.o is a prerequisite, and is missing, without any complaints. This is, of course, because I have a rule which gives a dependency from lex.yy.o to lex.yy.c, but which has n

[bug #27609] Stupid inference rule for yacc files can clobber C sources!

Follow-up Comment #9, bug #27609 (project make): What if these dangerous implicit rules made a rotating backup of their victim? What is the downside? mv foo.c.keep.1 foo.c.keep.2 mv foo.c foo.c.keep.1 mv y.tab.c foo.c ___ Repl

[bug #27609] Stupid inference rule for yacc files can clobber C sources!

Follow-up Comment #8, bug #27609 (project make): I was just burned by this again! I have a small project with "hc.l" lexer, and a "hc.c" source file. It's been working fine. My Makefile was generating lex.yy.c from hc.l, compiling hc.c to hc.o, and lex.yy.c to lex.yy.o, and linking everything.

[bug #27609] Stupid inference rule for yacc files can clobber C sources!

Follow-up Comment #7, bug #27609 (project make): Also, another consideration is that the prerequisite .y is involved in an explicit rule. If an implicit rule matches some file as a prerequisite, but that file is already used as a prerequisite in some rule, then those rules are competing. Maybe

[bug #27609] Stupid inference rule for yacc files can clobber C sources!

Follow-up Comment #6, bug #27609 (project make): I've thought about this a little bit more. Basically, here is what may be the real issue: the rule interferes with objects which are already entangle din other rules. Be it as it may that it's required by POSIX and let's take it for granted that w

[bug #27609] Stupid inference rule for yacc files can clobber C sources!

Follow-up Comment #4, bug #27609 (project make): By the way, this is quite bad. The behavior happens even if I have an explicit rule like this: foo.o: foo.c If there is a foo.y, foo.c is clobbered, even though foo.c exists. This is so retarded. The search for the prerequisite of foo.o must

[bug #27609] Stupid inference rule for yacc files can clobber C sources!

Follow-up Comment #3, bug #27609 (project make): Re: what can be done about it. Enough silly venting. How about the question of what can be done about it? I have an idea. How about a check to see whether the .c file to be clobbered is actually a yacc-generated file? If the file already exists,

[bug #27609] Stupid inference rule for yacc files can clobber C sources!

Follow-up Comment #2, bug #27609 (project make): If I have two different yacc files that generate different parsers in the same directory, then I'm going to be aware of that situation and resolve it. If I don't resolve it, then they will both clobber y.tab.c, which is my fault. I'm bitten by my o

[bug #18335] Addition of $(math ...) functions

Follow-up Comment #4, bug #18335 (project make): The make program does a lot of work by generating shell script fragments and running them. Not only are the lines of rule bodies shell scripts, but GNU makefiles make other uses of shell features. For instance, calling the find utility to locate ta

[bug #27609] Stupid inference rule for yacc files can clobber C sources!

URL: Summary: Stupid inference rule for yacc files can clobber C sources! Project: make Submitted by: kkylheku Submitted on: Mon 05 Oct 2009 12:36:09 PM PDT Severity: 3 - Normal