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