1# $NetBSD: directive-include-guard.mk,v 1.12 2023/08/11 04:56:31 rillig Exp $ 2# 3# Tests for multiple-inclusion guards in makefiles. 4# 5# A file that is guarded by a multiple-inclusion guard has one of the 6# following forms: 7# 8# .ifndef GUARD_VARIABLE 9# .endif 10# 11# .if !defined(GUARD_VARIABLE) 12# .endif 13# 14# .if !target(guard-target) 15# .endif 16# 17# When such a file is included for the second or later time, and the guard 18# variable or the guard target is defined, including the file has no effect, 19# as all its content is skipped. 20# 21# See also: 22# https://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html 23 24# Each of the following test cases creates a temporary file named after the 25# test case and writes some lines of text to that file. That file is then 26# included twice, to see whether the second '.include' is skipped. 27 28 29# This is the canonical form of a variable-based multiple-inclusion guard. 30INCS+= variable-ifndef 31LINES.variable-ifndef= \ 32 '.ifndef VARIABLE_IFNDEF' \ 33 'VARIABLE_IFNDEF=' \ 34 '.endif' 35# expect: Parse_PushInput: file variable-ifndef.tmp, line 1 36# expect: Skipping 'variable-ifndef.tmp' because 'VARIABLE_IFNDEF' is defined 37 38# A file that reuses a guard from a previous file (or whose guard is defined 39# for any other reason) is only processed once, to see whether it is guarded. 40# Its content is skipped, therefore the syntax error is not detected. 41INCS+= variable-ifndef-reuse 42LINES.variable-ifndef-reuse= \ 43 '.ifndef VARIABLE_IFNDEF' \ 44 'syntax error' \ 45 '.endif' 46# expect: Parse_PushInput: file variable-ifndef-reuse.tmp, line 1 47# expect: Skipping 'variable-ifndef-reuse.tmp' because 'VARIABLE_IFNDEF' is defined 48 49# Comments and empty lines do not affect the multiple-inclusion guard. 50INCS+= comments 51LINES.comments= \ 52 '\# comment' \ 53 '' \ 54 '.ifndef COMMENTS' \ 55 '\# comment' \ 56 'COMMENTS=\#comment' \ 57 '.endif' \ 58 '\# comment' 59# expect: Parse_PushInput: file comments.tmp, line 1 60# expect: Skipping 'comments.tmp' because 'COMMENTS' is defined 61 62# An alternative form uses the 'defined' function. It is more verbose than 63# the canonical form but avoids the '.ifndef' directive, as that directive is 64# not commonly used. 65INCS+= variable-if 66LINES.variable-if= \ 67 '.if !defined(VARIABLE_IF)' \ 68 'VARIABLE_IF=' \ 69 '.endif' 70# expect: Parse_PushInput: file variable-if.tmp, line 1 71# expect: Skipping 'variable-if.tmp' because 'VARIABLE_IF' is defined 72 73# A file that reuses a guard from a previous file (or whose guard is defined 74# for any other reason) is only processed once, to see whether it is guarded. 75# Its content is skipped, therefore the syntax error is not detected. 76INCS+= variable-if-reuse 77LINES.variable-if-reuse= \ 78 '.if !defined(VARIABLE_IF)' \ 79 'syntax error' \ 80 '.endif' 81# expect: Parse_PushInput: file variable-if-reuse.tmp, line 1 82# expect: Skipping 'variable-if-reuse.tmp' because 'VARIABLE_IF' is defined 83 84# Triple negation is so uncommon that it's not recognized, even though it has 85# the same effect as a single negation. 86INCS+= variable-if-triple-negation 87LINES.variable-if-triple-negation= \ 88 '.if !!!defined(VARIABLE_IF_TRIPLE_NEGATION)' \ 89 'VARIABLE_IF_TRIPLE_NEGATION=' \ 90 '.endif' 91# expect: Parse_PushInput: file variable-if-triple-negation.tmp, line 1 92# expect: Parse_PushInput: file variable-if-triple-negation.tmp, line 1 93 94# A conditional other than '.if' or '.ifndef' does not guard the file, even if 95# it is otherwise equivalent to the above accepted forms. 96INCS+= variable-ifdef-negated 97LINES.variable-ifdef-negated= \ 98 '.ifdef !VARIABLE_IFDEF_NEGATED' \ 99 'VARIABLE_IFDEF_NEGATED=' \ 100 '.endif' 101# expect: Parse_PushInput: file variable-ifdef-negated.tmp, line 1 102# expect: Parse_PushInput: file variable-ifdef-negated.tmp, line 1 103 104# The variable names in the '.if' and the assignment must be the same. 105INCS+= variable-name-mismatch 106LINES.variable-name-mismatch= \ 107 '.ifndef VARIABLE_NAME_MISMATCH' \ 108 'VARIABLE_NAME_DIFFERENT=' \ 109 '.endif' 110# expect: Parse_PushInput: file variable-name-mismatch.tmp, line 1 111# expect: Parse_PushInput: file variable-name-mismatch.tmp, line 1 112 113# The variable name '!VARNAME' cannot be used in an '.ifndef' directive, as 114# the '!' would be a negation. It is syntactically valid in a '.if !defined' 115# condition, but this case is so uncommon that the guard mechanism doesn't 116# accept '!' in the guard variable name. Furthermore, when defining the 117# variable, the character '!' has to be escaped, to prevent it from being 118# interpreted as the '!' dependency operator. 119INCS+= variable-name-exclamation 120LINES.variable-name-exclamation= \ 121 '.if !defined(!VARIABLE_NAME_EXCLAMATION)' \ 122 '${:U!}VARIABLE_NAME_EXCLAMATION=' \ 123 '.endif' 124# expect: Parse_PushInput: file variable-name-exclamation.tmp, line 1 125# expect: Parse_PushInput: file variable-name-exclamation.tmp, line 1 126 127# A variable name can contain a '!' in the middle, as that character is 128# interpreted as an ordinary character in conditions as well as on the left 129# side of a variable assignment. For guard variable names, the '!' is not 130# supported in any place, though. 131INCS+= variable-name-exclamation-middle 132LINES.variable-name-exclamation-middle= \ 133 '.ifndef VARIABLE_NAME!MIDDLE' \ 134 'VARIABLE_NAME!MIDDLE=' \ 135 '.endif' 136# expect: Parse_PushInput: file variable-name-exclamation-middle.tmp, line 1 137# expect: Parse_PushInput: file variable-name-exclamation-middle.tmp, line 1 138 139# A variable name can contain balanced parentheses, at least in conditions and 140# on the left side of a variable assignment. There are enough places in make 141# where parentheses or braces are handled inconsistently to make this naming 142# choice a bad idea, therefore these characters are not allowed in guard 143# variable names. 144INCS+= variable-name-parentheses 145LINES.variable-name-parentheses= \ 146 '.ifndef VARIABLE_NAME(&)PARENTHESES' \ 147 'VARIABLE_NAME(&)PARENTHESES=' \ 148 '.endif' 149# expect: Parse_PushInput: file variable-name-parentheses.tmp, line 1 150# expect: Parse_PushInput: file variable-name-parentheses.tmp, line 1 151 152# The guard condition must consist of only the guard variable, nothing else. 153INCS+= variable-ifndef-plus 154LINES.variable-ifndef-plus= \ 155 '.ifndef VARIABLE_IFNDEF_PLUS && VARIABLE_IFNDEF_SECOND' \ 156 'VARIABLE_IFNDEF_PLUS=' \ 157 'VARIABLE_IFNDEF_SECOND=' \ 158 '.endif' 159# expect: Parse_PushInput: file variable-ifndef-plus.tmp, line 1 160# expect: Parse_PushInput: file variable-ifndef-plus.tmp, line 1 161 162# The guard condition must consist of only the guard variable, nothing else. 163INCS+= variable-if-plus 164LINES.variable-if-plus= \ 165 '.if !defined(VARIABLE_IF_PLUS) && !defined(VARIABLE_IF_SECOND)' \ 166 'VARIABLE_IF_PLUS=' \ 167 'VARIABLE_IF_SECOND=' \ 168 '.endif' 169# expect: Parse_PushInput: file variable-if-plus.tmp, line 1 170# expect: Parse_PushInput: file variable-if-plus.tmp, line 1 171 172# The variable name in an '.ifndef' guard must be given directly, it must not 173# contain any '$' expression. 174INCS+= variable-ifndef-indirect 175LINES.variable-ifndef-indirect= \ 176 '.ifndef $${VARIABLE_IFNDEF_INDIRECT:L}' \ 177 'VARIABLE_IFNDEF_INDIRECT=' \ 178 '.endif' 179# expect: Parse_PushInput: file variable-ifndef-indirect.tmp, line 1 180# expect: Parse_PushInput: file variable-ifndef-indirect.tmp, line 1 181 182# The variable name in an '.if' guard must be given directly, it must not 183# contain any '$' expression. 184INCS+= variable-if-indirect 185LINES.variable-if-indirect= \ 186 '.if !defined($${VARIABLE_IF_INDIRECT:L})' \ 187 'VARIABLE_IF_INDIRECT=' \ 188 '.endif' 189# expect: Parse_PushInput: file variable-if-indirect.tmp, line 1 190# expect: Parse_PushInput: file variable-if-indirect.tmp, line 1 191 192# The variable name in the guard condition must only contain alphanumeric 193# characters and underscores. The place where the guard variable is defined 194# is more flexible, as long as the variable is defined at the point where the 195# file is included the next time. 196INCS+= variable-assign-indirect 197LINES.variable-assign-indirect= \ 198 '.ifndef VARIABLE_ASSIGN_INDIRECT' \ 199 '$${VARIABLE_ASSIGN_INDIRECT:L}=' \ 200 '.endif' 201# expect: Parse_PushInput: file variable-assign-indirect.tmp, line 1 202# expect: Skipping 'variable-assign-indirect.tmp' because 'VARIABLE_ASSIGN_INDIRECT' is defined 203 204# The time at which the guard variable is defined doesn't matter, as long as 205# it is defined at the point where the file is included the next time. 206INCS+= variable-assign-late 207LINES.variable-assign-late= \ 208 '.ifndef VARIABLE_ASSIGN_LATE' \ 209 'VARIABLE_ASSIGN_LATE_OTHER=' \ 210 'VARIABLE_ASSIGN_LATE=' \ 211 '.endif' 212# expect: Parse_PushInput: file variable-assign-late.tmp, line 1 213# expect: Skipping 'variable-assign-late.tmp' because 'VARIABLE_ASSIGN_LATE' is defined 214 215# The time at which the guard variable is defined doesn't matter, as long as 216# it is defined at the point where the file is included the next time. 217INCS+= variable-assign-nested 218LINES.variable-assign-nested= \ 219 '.ifndef VARIABLE_ASSIGN_NESTED' \ 220 '. if 1' \ 221 '. for i in once' \ 222 'VARIABLE_ASSIGN_NESTED=' \ 223 '. endfor' \ 224 '. endif' \ 225 '.endif' 226# expect: Parse_PushInput: file variable-assign-nested.tmp, line 1 227# expect: Skipping 'variable-assign-nested.tmp' because 'VARIABLE_ASSIGN_NESTED' is defined 228 229# If the guard variable is defined before the file is included for the first 230# time, the file is considered guarded as well. In such a case, the parser 231# skips almost all lines, as they are irrelevant, but the structure of the 232# top-level '.if/.endif' conditional can be determined reliably enough to 233# decide whether the file is guarded. 234INCS+= variable-already-defined 235LINES.variable-already-defined= \ 236 '.ifndef VARIABLE_ALREADY_DEFINED' \ 237 'VARIABLE_ALREADY_DEFINED=' \ 238 '.endif' 239VARIABLE_ALREADY_DEFINED= 240# expect: Parse_PushInput: file variable-already-defined.tmp, line 1 241# expect: Skipping 'variable-already-defined.tmp' because 'VARIABLE_ALREADY_DEFINED' is defined 242 243# If the guard variable is defined before the file is included the first time, 244# the file is processed but its content is skipped. If that same guard 245# variable is undefined when the file is included the second time, the file is 246# processed as usual. 247INCS+= variable-defined-then-undefined 248LINES.variable-defined-then-undefined= \ 249 '.ifndef VARIABLE_DEFINED_THEN_UNDEFINED' \ 250 '.endif' 251VARIABLE_DEFINED_THEN_UNDEFINED= 252UNDEF_BETWEEN.variable-defined-then-undefined= \ 253 VARIABLE_DEFINED_THEN_UNDEFINED 254# expect: Parse_PushInput: file variable-defined-then-undefined.tmp, line 1 255# expect: Parse_PushInput: file variable-defined-then-undefined.tmp, line 1 256 257# The whole file content must be guarded by a single '.if' conditional, not by 258# several, as each of these conditionals would require its separate guard. 259# This case is not expected to occur in practice, as the two parts would 260# rather be split into separate files. 261INCS+= variable-two-times 262LINES.variable-two-times= \ 263 '.ifndef VARIABLE_TWO_TIMES_1' \ 264 'VARIABLE_TWO_TIMES_1=' \ 265 '.endif' \ 266 '.ifndef VARIABLE_TWO_TIMES_2' \ 267 'VARIABLE_TWO_TIMES_2=' \ 268 '.endif' 269# expect: Parse_PushInput: file variable-two-times.tmp, line 1 270# expect: Parse_PushInput: file variable-two-times.tmp, line 1 271 272# When multiple files use the same guard variable name, the optimization of 273# skipping the file affects each of these files. 274# 275# Choosing unique guard names is the responsibility of the makefile authors. 276# A typical pattern of guard variable names is '${PROJECT}_${DIR}_${FILE}_MK'. 277# System-provided files typically start the guard names with '_'. 278INCS+= variable-clash 279LINES.variable-clash= \ 280 ${LINES.variable-if} 281# expect: Parse_PushInput: file variable-clash.tmp, line 1 282# expect: Skipping 'variable-clash.tmp' because 'VARIABLE_IF' is defined 283 284# The conditional must come before the assignment, otherwise the conditional 285# is useless, as it always evaluates to false. 286INCS+= variable-swapped 287LINES.variable-swapped= \ 288 'SWAPPED=' \ 289 '.ifndef SWAPPED' \ 290 '. error' \ 291 '.endif' 292# expect: Parse_PushInput: file variable-swapped.tmp, line 1 293# expect: Parse_PushInput: file variable-swapped.tmp, line 1 294 295# If the guard variable is undefined between the first and the second time the 296# file is included, the guarded file is included again. 297INCS+= variable-undef-between 298LINES.variable-undef-between= \ 299 '.ifndef VARIABLE_UNDEF_BETWEEN' \ 300 'VARIABLE_UNDEF_BETWEEN=' \ 301 '.endif' 302UNDEF_BETWEEN.variable-undef-between= \ 303 VARIABLE_UNDEF_BETWEEN 304# expect: Parse_PushInput: file variable-undef-between.tmp, line 1 305# expect: Parse_PushInput: file variable-undef-between.tmp, line 1 306 307# If the guard variable is undefined while the file is included the first 308# time, the guard does not have an effect, and the file is included again. 309INCS+= variable-undef-inside 310LINES.variable-undef-inside= \ 311 '.ifndef VARIABLE_UNDEF_INSIDE' \ 312 'VARIABLE_UNDEF_INSIDE=' \ 313 '.undef VARIABLE_UNDEF_INSIDE' \ 314 '.endif' 315# expect: Parse_PushInput: file variable-undef-inside.tmp, line 1 316# expect: Parse_PushInput: file variable-undef-inside.tmp, line 1 317 318# If the file does not define the guard variable, the guard does not have an 319# effect, and the file is included again. 320INCS+= variable-not-defined 321LINES.variable-not-defined= \ 322 '.ifndef VARIABLE_NOT_DEFINED' \ 323 '.endif' 324# expect: Parse_PushInput: file variable-not-defined.tmp, line 1 325# expect: Parse_PushInput: file variable-not-defined.tmp, line 1 326 327# The outermost '.if' must not have an '.elif' branch. 328INCS+= elif 329LINES.elif= \ 330 '.ifndef ELIF' \ 331 'ELIF=' \ 332 '.elif 1' \ 333 '.endif' 334# expect: Parse_PushInput: file elif.tmp, line 1 335# expect: Parse_PushInput: file elif.tmp, line 1 336 337# When a file with an '.if/.elif/.endif' conditional at the top level is 338# included, it is never optimized, as one of its branches is taken. 339INCS+= elif-reuse 340LINES.elif-reuse= \ 341 '.ifndef ELIF' \ 342 'syntax error' \ 343 '.elif 1' \ 344 '.endif' 345# expect: Parse_PushInput: file elif-reuse.tmp, line 1 346# expect: Parse_PushInput: file elif-reuse.tmp, line 1 347 348# The outermost '.if' must not have an '.else' branch. 349INCS+= else 350LINES.else= \ 351 '.ifndef ELSE' \ 352 'ELSE=' \ 353 '.else' \ 354 '.endif' 355# expect: Parse_PushInput: file else.tmp, line 1 356# expect: Parse_PushInput: file else.tmp, line 1 357 358# When a file with an '.if/.else/.endif' conditional at the top level is 359# included, it is never optimized, as one of its branches is taken. 360INCS+= else-reuse 361LINES.else-reuse= \ 362 '.ifndef ELSE' \ 363 'syntax error' \ 364 '.else' \ 365 '.endif' 366# expect: Parse_PushInput: file else-reuse.tmp, line 1 367# expect: Parse_PushInput: file else-reuse.tmp, line 1 368 369# The inner '.if' directives may have an '.elif' or '.else', and it doesn't 370# matter which of their branches are taken. 371INCS+= inner-if-elif-else 372LINES.inner-if-elif-else= \ 373 '.ifndef INNER_IF_ELIF_ELSE' \ 374 'INNER_IF_ELIF_ELSE=' \ 375 '. if 0' \ 376 '. elif 0' \ 377 '. else' \ 378 '. endif' \ 379 '. if 0' \ 380 '. elif 1' \ 381 '. else' \ 382 '. endif' \ 383 '. if 1' \ 384 '. elif 1' \ 385 '. else' \ 386 '. endif' \ 387 '.endif' 388# expect: Parse_PushInput: file inner-if-elif-else.tmp, line 1 389# expect: Skipping 'inner-if-elif-else.tmp' because 'INNER_IF_ELIF_ELSE' is defined 390 391# The guard can also be a target instead of a variable. Using a target as a 392# guard has the benefit that a target cannot be undefined once it is defined. 393# The target should be declared '.NOTMAIN'. Since the target names are 394# usually chosen according to a pattern that doesn't interfere with real 395# target names, they don't need to be declared '.PHONY' as they don't generate 396# filesystem operations. 397INCS+= target 398LINES.target= \ 399 '.if !target(__target.tmp__)' \ 400 '__target.tmp__: .NOTMAIN' \ 401 '.endif' 402# expect: Parse_PushInput: file target.tmp, line 1 403# expect: Skipping 'target.tmp' because '__target.tmp__' is defined 404 405# When used for system files, the target name may include '<' and '>', for 406# symmetry with the '.include <sys.mk>' directive. The characters '<' and '>' 407# are ordinary characters. 408INCS+= target-sys 409LINES.target-sys= \ 410 '.if !target(__<target-sys.tmp>__)' \ 411 '__<target-sys.tmp>__: .NOTMAIN' \ 412 '.endif' 413# expect: Parse_PushInput: file target-sys.tmp, line 1 414# expect: Skipping 'target-sys.tmp' because '__<target-sys.tmp>__' is defined 415 416# The target name may include variable references. These references are 417# expanded as usual. Due to the current implementation, the expressions are 418# evaluated twice: Once for checking whether the condition evaluates to true, 419# and once for determining the guard name. This double evaluation should not 420# matter in practice, as guard expressions are expected to be simple, 421# deterministic and without side effects. 422INCS+= target-indirect 423LINES.target-indirect= \ 424 '.if !target($${target-indirect.tmp:L})' \ 425 'target-indirect.tmp: .NOTMAIN' \ 426 '.endif' 427# expect: Parse_PushInput: file target-indirect.tmp, line 1 428# expect: Skipping 'target-indirect.tmp' because 'target-indirect.tmp' is defined 429 430# A common form of guard target is __${.PARSEFILE}__. This form can only be 431# used if all files using this form have unique basenames. To get a robust 432# pattern based on the same idea, use __${.PARSEDIR}/${.PARSEFILE}__ instead. 433# This form does not work when the basename contains whitespace characters, as 434# it is not possible to define a target with whitespace, not even by cheating. 435INCS+= target-indirect-PARSEFILE 436LINES.target-indirect-PARSEFILE= \ 437 '.if !target(__$${.PARSEFILE}__)' \ 438 '__$${.PARSEFILE}__: .NOTMAIN' \ 439 '.endif' 440# expect: Parse_PushInput: file target-indirect-PARSEFILE.tmp, line 1 441# expect: Skipping 'target-indirect-PARSEFILE.tmp' because '__target-indirect-PARSEFILE.tmp__' is defined 442 443# Two files with different basenames can both use the same syntactic pattern 444# for the target guard name, as the expressions expand to different strings. 445INCS+= target-indirect-PARSEFILE2 446LINES.target-indirect-PARSEFILE2= \ 447 '.if !target(__$${.PARSEFILE}__)' \ 448 '__$${.PARSEFILE}__: .NOTMAIN' \ 449 '.endif' 450# expect: Parse_PushInput: file target-indirect-PARSEFILE2.tmp, line 1 451# expect: Skipping 'target-indirect-PARSEFILE2.tmp' because '__target-indirect-PARSEFILE2.tmp__' is defined 452 453# Using plain .PARSEFILE without .PARSEDIR leads to name clashes. The include 454# guard is the same as in the test case 'target-indirect-PARSEFILE', as the 455# guard name only contains the basename but not the directory name. So even 456# without defining the guard variable, the file is considered guarded. 457INCS+= subdir/target-indirect-PARSEFILE 458LINES.subdir/target-indirect-PARSEFILE= \ 459 '.if !target(__$${.PARSEFILE}__)' \ 460 '.endif' 461# expect: Parse_PushInput: file subdir/target-indirect-PARSEFILE.tmp, line 1 462# expect: Skipping 'subdir/target-indirect-PARSEFILE.tmp' because '__target-indirect-PARSEFILE.tmp__' is defined 463 464# Another common form of guard target is __${.PARSEDIR}/${.PARSEFILE}__ 465# or __${.PARSEDIR:tA}/${.PARSEFILE}__ to be truly unique. 466INCS+= target-indirect-PARSEDIR-PARSEFILE 467LINES.target-indirect-PARSEDIR-PARSEFILE= \ 468 '.if !target(__$${.PARSEDIR}/$${.PARSEFILE}__)' \ 469 '__$${.PARSEDIR}/$${.PARSEFILE}__: .NOTMAIN' \ 470 '.endif' 471# expect: Parse_PushInput: file target-indirect-PARSEDIR-PARSEFILE.tmp, line 1 472# expect: Skipping 'target-indirect-PARSEDIR-PARSEFILE.tmp' because '__target-indirect-PARSEDIR-PARSEFILE.tmp__' is defined 473# The actual target starts with '__${.OBJDIR}/', see the .rawout file, but the 474# string '${.OBJDIR}/' gets stripped in post processing. 475 476# Using the combination of '.PARSEDIR' and '.PARSEFILE', a file in a 477# subdirectory gets a different guard target name than the previous one. 478INCS+= subdir/target-indirect-PARSEDIR-PARSEFILE 479LINES.subdir/target-indirect-PARSEDIR-PARSEFILE= \ 480 '.if !target(__$${.PARSEDIR}/$${.PARSEFILE}__)' \ 481 '__$${.PARSEDIR}/$${.PARSEFILE}__: .NOTMAIN' \ 482 '.endif' 483# expect: Parse_PushInput: file subdir/target-indirect-PARSEDIR-PARSEFILE.tmp, line 1 484# expect: Skipping 'subdir/target-indirect-PARSEDIR-PARSEFILE.tmp' because '__subdir/target-indirect-PARSEDIR-PARSEFILE.tmp__' is defined 485# The actual target starts with '__${.OBJDIR}/', see the .rawout file, but the 486# string '${.OBJDIR}/' gets stripped in post processing. 487 488# If the guard target is not defined when including the file the next time, 489# the file is processed again. 490INCS+= target-unguarded 491LINES.target-unguarded= \ 492 '.if !target(target-unguarded)' \ 493 '.endif' 494# expect: Parse_PushInput: file target-unguarded.tmp, line 1 495# expect: Parse_PushInput: file target-unguarded.tmp, line 1 496 497# The guard condition must consist of only the guard target, nothing else. 498INCS+= target-plus 499LINES.target-plus= \ 500 '.if !target(target-plus) && 1' \ 501 'target-plus: .NOTMAIN' \ 502 '.endif' 503# expect: Parse_PushInput: file target-plus.tmp, line 1 504# expect: Parse_PushInput: file target-plus.tmp, line 1 505 506# If the guard target is defined before the file is included the first time, 507# the file is read once and then considered guarded. 508INCS+= target-already-defined 509LINES.target-already-defined= \ 510 '.if !target(target-already-defined)' \ 511 'target-already-defined: .NOTMAIN' \ 512 '.endif' 513target-already-defined: .NOTMAIN 514# expect: Parse_PushInput: file target-already-defined.tmp, line 1 515# expect: Skipping 'target-already-defined.tmp' because 'target-already-defined' is defined 516 517# A target name cannot contain the character '!'. In the condition, the '!' 518# is syntactically valid, but in the dependency declaration line, the '!' is 519# interpreted as the '!' dependency operator, no matter whether it occurs at 520# the beginning or in the middle of a target name. Escaping it as '${:U!}' 521# doesn't work, as the whole line is first expanded and then scanned for the 522# dependency operator. Escaping it as '\!' doesn't work either, even though 523# the '\' escapes the '!' from being a dependency operator, but when reading 524# the target name, the '\' is kept, resulting in the target name 525# '\!target-name-exclamation' instead of '!target-name-exclamation'. 526INCS+= target-name-exclamation 527LINES.target-name-exclamation= \ 528 '.if !target(!target-name-exclamation)' \ 529 '\!target-name-exclamation: .NOTMAIN' \ 530 '.endif' 531# expect: Parse_PushInput: file target-name-exclamation.tmp, line 1 532# expect: Parse_PushInput: file target-name-exclamation.tmp, line 1 533 534 535# Now run all test cases by including each of the files twice and looking at 536# the debug output. The files that properly guard against multiple inclusion 537# generate a 'Skipping' line, the others repeat the 'Parse_PushInput' line. 538# 539# Some debug output lines are suppressed in the .exp file, see ./Makefile. 540.for i in ${INCS} 541. for fname in $i.tmp 542_:= ${fname:H:N.:@dir@${:!mkdir -p ${dir}!}@} 543_!= printf '%s\n' ${LINES.$i} > ${fname} 544.MAKEFLAGS: -dp 545.include "${.CURDIR}/${fname}" 546.undef ${UNDEF_BETWEEN.$i:U} 547.include "${.CURDIR}/${fname}" 548.MAKEFLAGS: -d0 549_!= rm ${fname} 550_:= ${fname:H:N.:@dir@${:!rmdir ${dir}!}@} 551. endfor 552.endfor 553 554all: 555