[bug #35132] Side effects of .SECONDARY with no targets not documented
URL: http://savannah.gnu.org/bugs/?35132 Summary: Side effects of .SECONDARY with no targets not documented Project: make Submitted by: None Submitted on: Tue 20 Dec 2011 10:07:20 PM UTC Severity: 3 - Normal Item Group: Documentation Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 3.82 Operating System: POSIX-Based Fixed Release: None Triage Status: None ___ Details: There are some side effects associated with intermediate/secondary targets that aren't documented in any real detail in the documentation. The documentation for .SECONDARY gives the impression you can use .SECONDARY to disable automatic deletion of intermediate targets, but doing so causes a number of side effects that produce unpredictable behavior in a build. Unfortunately, I do not have a concise or publishable example demonstrating the problem; however, I outlined it on this thread: http://groups.google.com/group/gnu.utils.bug/browse_frm/thread/d882703f60b20ea5?hl=en# -Brian ___ Reply to this item at: http://savannah.gnu.org/bugs/?35132 ___ 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 #35133] Pattern rules used as dependencies for .PRECIOUS don't actually do pattern matching
URL:
http://savannah.gnu.org/bugs/?35133
Summary: Pattern rules used as dependencies for .PRECIOUS
don't actually do pattern matching
Project: make
Submitted by: None
Submitted on: Tue 20 Dec 2011 10:17:46 PM UTC
Severity: 3 - Normal
Item Group: Bug
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Component Version: 3.82
Operating System: POSIX-Based
Fixed Release: None
Triage Status: None
___
Details:
Simple example:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
all: some_target_blah.o stuff.o
@echo $@, $
%.y:
@echo $@
some_target%.cc : %.y
@echo $@, ${TEST}
%.cc:
@echo $@, ${TEST}
%.o : %.cc
@echo $@, $
#1
%.cc : TEST := stuff
#2
.PRECIOUS: %.cc
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
In the above example, pattern-matching is used in a few different ways; the
two I'm drawing attention to in this bug report are #1 and #2.
#1 causes *EVERY* .cc file to have TEST set. However, in #2, the pattern
specified as a dependency of .PRECIOUS only applies to files built using a
rule of the form:
%.cc : whatever
Since 'some_target_blah.o' is built using a different pattern, the .PRECIOUS
directive doesn't apply to it; thus, make will still try to remove that file
when it is finished running.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?35133
___
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 #35134] Add a special target or variable that induces the same behavior as '-r'
URL: http://savannah.gnu.org/bugs/?35134 Summary: Add a special target or variable that induces the same behavior as '-r' Project: make Submitted by: None Submitted on: Tue 20 Dec 2011 10:20:38 PM UTC Severity: 3 - Normal Item Group: Enhancement Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 3.82 Operating System: POSIX-Based Fixed Release: None Triage Status: None ___ Details: The '-r' switch prevents inclusion of built-in rules and variables. I'd like to have the means to induce this behavior from the makefile. ___ Reply to this item at: http://savannah.gnu.org/bugs/?35134 ___ 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 #35135] $() constructs that span multiple lines may add un-intended newlines
URL:
http://savannah.gnu.org/bugs/?35135
Summary: $() constructs that span multiple lines may add
un-intended newlines
Project: make
Submitted by: None
Submitted on: Tue 20 Dec 2011 10:28:41 PM UTC
Severity: 3 - Normal
Item Group: Bug
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Component Version: 3.82
Operating System: POSIX-Based
Fixed Release: None
Triage Status: None
___
Details:
Example:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
define SOME_MACRO =
$(if ${SOMETHING}
, RESULT1
, RESULT2
)
endef
%.o : %.cc
${CC} ${FLAGS} ${SOME_MACRO} ${MORE_FLAGS} ${} -o ${@}
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
In 3.81 this won't work at all -- $(if ...) statements won't span multiple
lines correctly in that version. In 3.82, it parses correctly but inserts
newlines. The net behavior is ${CC} gets executed with ${FLAGS}, and may or
may not include either RESULT1 or RESULT2, but ${MORE_FLAGS} and everything
past it gets executed separately within the sub-shell.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?35135
___
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 #35133] Pattern rules used as dependencies for .PRECIOUS don't actually do pattern matching
Update of bug #35133 (project make): Item Group: Bug = Enhancement ___ Follow-up Comment #1: The .PRECIOUS pseudo-target is behaving as documented: You can also list the target pattern of an implicit rule (such as `%.o') as a prerequisite file of the special target `.PRECIOUS' to preserve intermediate files created by rules whose target patterns match that file's name. And so are pattern-specific variable assignments: In addition to target-specific variable values, GNU `make' supports pattern-specific variable values. In this form, the variable is defined for any target that matches the pattern specified. This is not a bug; the system is behaving as documented. We can consider changing the behavior of, for example, the .PRECIOUS target so that patterns simply match any target, like other pseudo-targets that take patterns, but we'd have to think very carefully about the backward-compatibility implications of this. I'll leave this open as an enhancement request. ___ Reply to this item at: http://savannah.gnu.org/bugs/?35133 ___ 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 #35134] Add a special target or variable that induces the same behavior as '-r'
Update of bug #35134 (project make): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #1: You can get the behavior you want by adding this to your makefile: .SUFFIXES: MAKEFLAGS += -r See bug #20501 ___ Reply to this item at: http://savannah.gnu.org/bugs/?35134 ___ 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 #20501] MAKEFLAGS += -rR doesn't turn off default suffix rules, variables
Follow-up Comment #9, bug #20501 (project make): It's not completely true that -p shows the rules as if they were there. Recall that there are two types of implicit rules in GNU make: suffix rules and pattern rules. If you use MAKEFLAGS+=-r then the _pattern rules_ will not be present in the -p output. However, MAKEFLAGS+=-r is not the same as make -r because the latter ALSO prevents suffix rules from being defined, while the former does not. The former only applies to pattern rules. That's why in the makefile you need BOTH the .SUFFIXES: special target AND the MAKEFLAGS+=-r. Having the .SUFFIXES: special target set to empty ensures that no suffix rules are searched but it does NOT remove all the suffix rules from the database. So they still show up with -p, but they don't have any impact on the algorithms make uses to build targets. ___ Reply to this item at: http://savannah.gnu.org/bugs/?20501 ___ 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 #20501] MAKEFLAGS += -rR doesn't turn off default suffix rules, variables
Update of bug #20501 (project make): Operating System: POSIX-Based = Any ___ Reply to this item at: http://savannah.gnu.org/bugs/?20501 ___ 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 #20501] MAKEFLAGS += -rR doesn't turn off default suffix rules, variables
Update of bug #20501 (project make): Triage Status:None = Verified ___ Reply to this item at: http://savannah.gnu.org/bugs/?20501 ___ 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 #35135] $() constructs that span multiple lines may add un-intended newlines
Update of bug #35135 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This is expected behavior. One of the most important _features_ of
define/endef is that newlines are preserved. It's the only way to get
newlines into variable values, which is important in conjunction with $(eval
...) among other places.
If you want to embed newlines in the define but not have them in the result,
you must use backslashes to escape them; this works as expected:
define SOME_MACRO =
$(if ${SOMETHING}
, RESULT1
, RESULT2
)
endef
___
Reply to this item at:
http://savannah.gnu.org/bugs/?35135
___
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 #35132] Side effects of .SECONDARY with no targets not documented
On Tue, Dec 20, 2011 at 2:07 PM, anonymous invalid.nore...@gnu.org wrote: There are some side effects associated with intermediate/secondary targets that aren't documented in any real detail in the documentation. The documentation for .SECONDARY gives the impression you can use .SECONDARY to disable automatic deletion of intermediate targets, but doing so causes a number of side effects that produce unpredictable behavior in a build. Unfortunately, I do not have a concise or publishable example demonstrating the problem; however, I outlined it on this thread: http://groups.google.com/group/gnu.utils.bug/browse_frm/thread/d882703f60b20ea5?hl=en# To confirm, when you say thread, you mean my single post, right? I want to be sure that link isn't leaving off replies or something... That said, your post references rules that build symlinks to other files...and then you leave out important details of the cases that cause problems. If you don't have the time to find a minimal test case, can you at least spend the time to figure out the conditions under which the problem occurs? If not, how are we, who don't have access to your system, supposed to figure that out? You might get lucky...or you might just be pissing into the wind. So: does the problem only occur when the symlink already exists? Or when the symlink *doesn't* exist? Is this a recursive make setup? If so, which makefiles have which rules? How can we debug this when you don't provide *ANY* examples of a rule for building one of those symlinks? As for issue problem with .PRECIOUS, well, it works with patterns for me; please provide an actual example. Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
