1# $NetBSD: dep-var.mk,v 1.11 2023/12/19 19:33:40 rillig Exp $ 2# 3# Tests for variable references in dependency declarations. 4# 5# Uh oh, this feels so strange that probably nobody uses it. But it seems to 6# be the only way to reach the lower half of SuffExpandChildren. 7 8.MAKEFLAGS: -dv 9 10# expect: Var_Parse: ${UNDEF1} (eval-defined) 11# Even though undefined expressions should lead to errors, no error message is 12# generated for this line. The expression ${UNDEF1} simply expands 13# to an empty string. 14all: ${UNDEF1} 15 16# Using a double dollar in order to circumvent immediate expression expansion 17# feels like unintended behavior. At least the manual page says nothing at 18# all about defined or undefined variables in dependency lines. 19# 20# At the point where the expression ${DEF2} is expanded, the variable DEF2 21# is defined, so everything's fine. 22all: $${DEF2} a-$${DEF2}-b 23 24# This variable is not defined at all. 25# XXX: The -dv log says later when expanding the sources of 'all': 26# Var_Parse: ${UNDEF3} (eval-defined) 27# but no error message is generated for this line, just like for UNDEF1. 28# The expression ${UNDEF3} simply expands to an empty string. 29all: $${UNDEF3} 30 31# Try out how many levels of indirection are really expanded in dependency 32# lines. 33# 34# The first level of indirection is the $$ in the dependency line. 35# When the dependency line is parsed, it is resolved to the string 36# "${INDIRECT_1}". At this point, the dollar is just an ordinary character, 37# waiting to be expanded at some later point. 38# 39# Later, in SuffExpandChildren, that expression is expanded again by calling 40# Var_Parse, and this time, the result is the string "1-2-${INDIRECT_2}-2-1". 41# 42# This string is not expanded anymore by Var_Parse. But there is another 43# effect. Now DirExpandCurly comes into play and expands the curly braces 44# in this filename pattern, resulting in the string "1-2-$INDIRECT_2-2-1". 45# As of 2020-09-03, the test dir.mk contains further details on this topic. 46# 47# Finally, this string is assigned to the local ${.TARGET} variable. This 48# variable is expanded when the shell command is generated. At that point, 49# the $I is expanded. Since the variable I is not defined, it expands to 50# the empty string. This way, the final output is the string 51# "1-2-NDIRECT_2-2-1", which differs from the actual name of the target. 52# For exactly this reason, it is not recommended to use dollar signs in 53# target names. 54# 55# The number of actual expansions is way more than one might expect, 56# therefore this feature is probably not widely used. 57# 58all: 1-$${INDIRECT_1}-1 59INDIRECT_1= 2-$${INDIRECT_2}-2 60INDIRECT_2= 3-$${INDIRECT_3}-3 61INDIRECT_3= indirect 62 63UNDEF1= undef1 64DEF2= def2 65 66# Cover the code in SuffExpandChildren that deals with malformed 67# expressions. 68# 69# This seems to be an edge case that never happens in practice, and it would 70# probably be appropriate to just error out in such a case. 71# 72# To trigger this piece of code, the variable name must contain "$)" or "$:" 73# or "$)" or "$$". Using "$:" does not work since the dependency line is 74# fully expanded before parsing, therefore any ':' in a target or source name 75# would be interpreted as a dependency operator instead. 76all: $$$$) 77 78# The $$INDIRECT in the following line is treated like the dependency of the 79# "all" target, that is, the "$$I" is first expanded to "$I", and in a second 80# round of expansion, the "$I" expands to nothing since the variable "I" is 81# undefined. 82# 83# Since 2020-09-13, this generates a parse error in lint mode (-dL), but not 84# in normal mode since ParseDependency does not handle any errors after 85# calling Var_Parse. 86# expect: Var_Parse: ${:U\$)}: (eval-defined) 87# expect: Var_Parse: $INDIRECT_2-2-1 $): (parse-only) 88# expect: Var_Parse: $): (parse-only) 89undef1 def2 a-def2-b 1-2-$$INDIRECT_2-2-1 ${:U\$)}: 90 @echo ${.TARGET:Q} 91 92.MAKEFLAGS: -d0 93 94# XXX: The exit status is still 0, even though Parse_Error is called with 95# PARSE_FATAL in SuffExpandChildren. The exit status is only affected by 96# parse errors when they occur in the parsing phase, see Parse_File. 97