bug? $(warning)/$(error) evaluated from inside a comment in a 'define'?
Hi, Makers! i just discovered a Make behaviour which really surprises me. While that in itself is nothing new ;), this one certainly violates the principal of least astonishment: When a $(warning) or $(error) is inside a 'define', it is evaluated even if it is part of a comment. A demonstration: [EMAIL PROTECTED]:~/cvs/www.t5$ make --version GNU Make 3.81 ... Input file to reproduce problem: #!/usr/bin/make -f ## default: all define bogo # $(warning this should not be evaluated here: (bogo $(1))) abc := $(1) endef $(foreach ARG,abc def ghi,$(eval $(call bogo,$(ARG all: ## [EMAIL PROTECTED]:~/cvs/www.t5$ make -f bug.make bug.make:11: this should not be evaluated here: (bogo abc) bug.make:11: this should not be evaluated here: (bogo def) bug.make:11: this should not be evaluated here: (bogo ghi) make: Nothing to be done for `default'. As far as i understand, comments are comments, regardless of the context. ??? My assumption is that this also applies to other $(functions) inside such a comment, but i haven't tried it out. Or is this a strange as-designed behaviour? Many thanks in advance for your time and your awesome product, (No, that's not sarcasm! i'm a huge fan!) -- - [EMAIL PROTECTED] http://www.wanderinghorse.net signature.asc Description: This is a digitally signed message part. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: bug? $(warning)/$(error) evaluated from inside a comment in a 'define'?
On 6/20/07, Stephan Beal [EMAIL PROTECTED] wrote: When a $(warning) or $(error) is inside a 'define', it is evaluated even if it is part of a comment. A demonstration: I think the test case to demonstrate this bug can be simplified as: define bogo # $(warning this should not happen) endef all: $(bogo) And make produces $ make -f a.mk a.mk:5: this should not happen # Yeah, it's really funny. Also, $(info ...) and its families seem to evaluate too early according to my vague impression. Cheers, agentz ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: bug? $(warning)/$(error) evaluated from inside a comment in a 'define'?
On 6/19/07, Stephan Beal [EMAIL PROTECTED] wrote: ... When a $(warning) or $(error) is inside a 'define', it is evaluated even if it is part of a comment. The above statement is nonsensical. If something is inside a define, is not inside a comment. define bogo # $(warning this should not be evaluated here: (bogo $(1))) abc := $(1) endef $(foreach ARG,abc def ghi,$(eval $(call bogo,$(ARG Okay, so you've defined a variable, 'bogo', whose value consists of two lines, the first of which has a '#' as its first non-whitespace character. It isn't a comment at that point, it's just a line with a leading '#'. So why isn't it being treated as a comment when you evaluate it? Answer: it *is*, but the expansion of the variables and functions in the value of 'bogo' takes place before 'eval' does anything. Consider this: define bogo2 # $(warning foo! $(1)) endef all: echo '$(bogo2)' echo '$(call bogo2,baz)' $ gmake -f m2 m2:6: foo! m2:6: foo! baz echo '# ' # echo '# ' # $ When $(bogo2) is expanded, whether directly or via $(call), make recursively expands the variables and functions inside its value. That's all without $(eval) being used at all. As far as i understand, comments are comments, regardless of the context. ??? Not at all. A comment is only a comment when being read, either as part of the raw makefile or as the first step in eval's actual operation. (Then there are comments in the commands for rules, where if they're indented with a tab then make sees them as normal parts of the commands and passes them to the shell...which then will often ignore them based on *its* rules.) Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: bug? $(warning)/$(error) evaluated from inside a comment in a 'define'?
On 6/19/07, Agent Zhang [EMAIL PROTECTED] wrote: ... I think the test case to demonstrate this bug can be simplified as: define bogo # $(warning this should not happen) endef all: $(bogo) And make produces $ make -f a.mk a.mk:5: this should not happen # Yeah, it's really funny. Funny in the this computer is broken: it only does what I tell it to, not want I want! sense, I presume. You told it to expand $(bogo) completely, so it did. If you don't want that, then tell it to only expand it one level, with $(value): $ cat Makefile define bogo # $(warning this should not be evaluated here) endef all: echo '$(value bogo)' $ make echo '# $(warning this should not be evaluated here)' # $(warning this should not be evaluated here) $ The trick is that you can't easily mix $(call) and $(value): there's no way to say give me the value of 'bogo', expanding *only* the argument variables $(1), $(2), ... and not other variables or functions in 'bogo's value. You have to indicate which variables should have their expansion delayed *in the value of bogo*, by doubling their '$': $ cat Makefile define bogo # $$(warning this should not be evaluated here: $(1)) endef all: echo '$(call bogo,foo)' $ make echo '# $(warning this should not be evaluated here: foo)' # $(warning this should not be evaluated here: foo) $ If you were to say $(eval $(call bogo,foo)) in that file, you wouldn't get a warning because the $(warning) wouldn't be expanded before the eval, and in the eval it would be in a comment. Also, $(info ...) and its families seem to evaluate too early according to my vague impression. Like all variables and functions, they are expanded when the context they are in is expanded. Section 3.9 of the info pages describes which contexts are subject to immediately expansion and which are deferred until the containing variable is expanded or the rule's commands are invokved. Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
