[bug #17521] target-specific variables inluding semicolon

URL: 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: B

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

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

[bug #17529] Variable set with $(shell date '+%Y%m%d-%H%M%S') changes mid-make

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

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

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 doc