[bug #17521] target-specific variables inluding semicolon
URL: http://savannah.gnu.org/bugs/?17521 Summary: target-specific variables inluding semicolon Project: make Submitted by: None Submitted on: 金曜日 2006年08月25日 at 08:43 UTC Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Component Version: 3.81 Operating System: MS Windows Fixed Release: None ___ Details: $ make --version 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 i686-pc-cygwin $ $ cat Makefile test: HELLO = 'hello \ world' test2: HELLO2 = 'hello; \ world' test : @echo $(HELLO) test2 : @echo $(HELLO2) $ make test hello world $ make test2 hello; \ world I expect 'hello; world'. Regards. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17521 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #17521] target-specific variables inluding semicolon
Follow-up Comment #1, bug #17521 (project make): This is not a bug, but a documented change in behavior, intended to bring GNU Make in line with Posix specification for Make. From the NEWS file: * WARNING: Backward-incompatibility! In order to comply with POSIX, the way in which GNU make processes backslash-newline sequences in command strings has changed. If your makefiles use backslash-newline sequences inside of single-quoted strings in command scripts you will be impacted by this change. See the GNU make manual subsection Splitting Command Lines (node Splitting Lines), in section Command Syntax, chapter Writing the Commands in Rules, for details. In other words, your Makefile violates Posix rules for Make; in order to fix your Makefile, either use double quotes instead of single quotes, or put the single-quoted string into a Make variable and use that variable in rule's commands. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17521 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #17521] target-specific variables inluding semicolon
Follow-up Comment #2, bug #17521 (project make): Actually, Eli, if the example shown is accurate (I haven't tried it) then this seems to be a bug. First note that the two cases behave differently: the one without the semicolon strips the backslash and the one with it does not. That can't be right. Second, the text you're quoting applies to backslashes inside the command script: these backslashes are in variable values (even though they're target-specific variables they still follow the rules for setting variables) and the behavior of backslashes in variable values didn't change. Again, I haven't looked at this at all but offhand I'd say there's some issue with the parser finding semicolons in target-specific variables: remember make needs to handle semicolons in a normal target definition such as all: ; @echo all specially. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17521 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #17529] Variable set with $(shell date '+%Y%m%d-%H%M%S') changes mid-make
URL: http://savannah.gnu.org/bugs/?17529 Summary: Variable set with $(shell date '+%Y%m%d-%H%M%S') changes mid-make Project: make Submitted by: terrycojones Submitted on: Friday 08/25/2006 at 20:32 Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Component Version: 3.81 Operating System: POSIX-Based Fixed Release: None ___ Details: I have a simple Makefile: base = xxx-$(shell date '+%Y%m%d-%H%M%S') t: @echo $(base) @echo $(base) @echo $(base) @echo $(base) @echo $(base) @echo $(base) Sometimes when I 'make t' from the shell, the value of $(base) changes: $ make t xxx-20060825-222523 xxx-20060825-222523 xxx-20060825-222523 xxx-20060825-222523 xxx-20060825-222524 xxx-20060825-222524 This only happens rarely, perhaps once every 20 runs. I'm on Mac OS X 10.3.9 running a freshly built make 3.81. I can put some @sleep 5 lines into the above t target and still see the same thing happen. Terry ___ Reply to this item at: http://savannah.gnu.org/bugs/?17529 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: [bug #17529] Variable set with $(shell date '+%Y%m%d-%H%M%S') changes mid-make
base = xxx-$(shell date '+%Y%m%d-%H%M%S') Perhaps you wanted := instead of =. The difference is explained in (for example): http://www.gnu.org/software/make/manual/html_node/Reading-Makefiles.html #Reading-Makefiles - Martin's Outlook, BlueArc Engineering ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: [bug #17529] Variable set with $(shell date '+%Y%m%d-%H%M%S') changes mid-make
all variables are expanded exactly once - whether they are immediate or deferred No. It might sound like that but that's definitely, definitely, definitely not what happens. Deferred variables are expanded again every time they're used. I thought perhaps I'd quoted the wrong part of the documentation because, reading it again, I think you're right that it isn't clear. Searching for deferred didn't find me any other, clearer part. Perhaps a clarification patch would be in order. Try the := idea. I bet you can't break it. Another idea that might be more convincing: base = $(shell date --iso=ns 12) That sends the output of date(1) to stderr, where you'll see it directly, once for each time it's invoked. - Martin's Outlook, BlueArc Engineering ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
