xref: /freebsd/contrib/bmake/unit-tests/dep-var.mk (revision 6a7405f5a6b639682cacf01e35d561411ff556aa)
1# $NetBSD: dep-var.mk,v 1.13 2025/01/14 21:23:17 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# In a dependency line, an undefined expressions expands to an empty string.
11# expect: Var_Parse: ${UNDEF1} (eval)
12all: ${UNDEF1}
13
14# Using a double dollar in order to circumvent immediate expression expansion
15# feels like unintended behavior.  At least the manual page says nothing at
16# all about defined or undefined variables in dependency lines.
17#
18# At the point where the expression ${DEF2} is expanded, the variable DEF2
19# is defined, so everything's fine.
20all: $${DEF2} a-$${DEF2}-b
21
22# This variable is neither defined now nor later.
23all: $${UNDEF3}
24
25# Try out how many levels of indirection are really expanded in dependency
26# lines.
27#
28# The first level of indirection is the $$ in the dependency line.
29# When the dependency line is parsed, it is resolved to the string
30# "${INDIRECT_1}".  At this point, the dollar is just an ordinary character,
31# waiting to be expanded at some later point.
32#
33# Later, in SuffExpandChildren, that expression is expanded again by calling
34# Var_Parse, and this time, the result is the string "1-2-${INDIRECT_2}-2-1".
35#
36# This string is not expanded anymore by Var_Parse.  But there is another
37# effect.  Now DirExpandCurly comes into play and expands the curly braces
38# in this filename pattern, resulting in the string "1-2-$INDIRECT_2-2-1".
39# As of 2020-09-03, the test dir.mk contains further details on this topic.
40#
41# Finally, this string is assigned to the local ${.TARGET} variable.  This
42# variable is expanded when the shell command is generated.  At that point,
43# the $I is expanded.  Since the variable I is not defined, it expands to
44# the empty string.  This way, the final output is the string
45# "1-2-NDIRECT_2-2-1", which differs from the actual name of the target.
46# For exactly this reason, it is not recommended to use dollar signs in
47# target names.
48#
49# The number of actual expansions is way more than one might expect,
50# therefore this feature is probably not widely used.
51#
52all: 1-$${INDIRECT_1}-1
53INDIRECT_1=	2-$${INDIRECT_2}-2
54INDIRECT_2=	3-$${INDIRECT_3}-3
55INDIRECT_3=	indirect
56
57UNDEF1=	undef1
58DEF2=	def2
59
60# Cover the code in SuffExpandChildren that deals with malformed
61# expressions.
62#
63# This seems to be an edge case that never happens in practice, and it would
64# probably be appropriate to just error out in such a case.
65#
66# To trigger this piece of code, the variable name must contain "$)" or "$:"
67# or "$)" or "$$".  Using "$:" does not work since the dependency line is
68# fully expanded before parsing, therefore any ':' in a target or source name
69# would be interpreted as a dependency operator instead.
70all: $$$$)
71
72# The $$INDIRECT in the following line is treated like the dependency of the
73# "all" target, that is, the "$$I" is first expanded to "$I", and in a second
74# round of expansion, the "$I" expands to nothing since the variable "I" is
75# undefined.
76#
77# Since 2020-09-13, this generates a parse error in lint mode (-dL), but not
78# in normal mode since ParseDependency does not handle any errors after
79# calling Var_Parse.
80# expect: Var_Parse: ${:U\$)}: (eval)
81# expect: Var_Parse: $INDIRECT_2-2-1 $): (parse)
82# expect: Var_Parse: $): (parse)
83undef1 def2 a-def2-b 1-2-$$INDIRECT_2-2-1 ${:U\$)}:
84	@echo ${.TARGET:Q}
85
86.MAKEFLAGS: -d0
87