1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
# Check reporting of missing inputs (including missing inputs produced by other
# commands).
# Run an initial build which fails on the command.
#
# RUN: rm -rf %t.build
# RUN: mkdir -p %t.build
# RUN: cp %s %t.build/build.llbuild
# RUN: %{llbuild} buildsystem build --serial --scheduler fifo --chdir %t.build &> %t.out || true
# RUN: %{FileCheck} %s --input-file %t.out --check-prefix=CHECK-FAILURE
#
# CHECK-FAILURE: cannot build 'output-1' due to missing inputs: 'input'
# CHECK-FAILURE-NOT: missing input 'output-2' and no rule to build it
# RUN: touch %t.build/input
# RUN: %{llbuild} buildsystem build --serial --chdir %t.build &> %t2.out || true
# RUN: %{FileCheck} %s --input-file %t2.out --check-prefix=CHECK-FAILURE-2
#
# At this point, we have unblocked the commands, and commands are allowed to run
# against missing outputs of previous commands (under the expectation that the
# commands themselves will diagnose errors). This approach allows transparent
# support of commands which may not produce an output (as long as the consumer
# is prepared to handle this), but we could also diagnose missing outputs as a
# response to the producing command to get stronger consistency checking.
#
# CHECK-FAILURE-2-NOT: missing input 'output-2' and no rule to build it
# CHECK-FAILURE-2: cp: {{.*}}output-2{{.*}}: No such file
client:
name: basic
targets:
"": ["output"]
commands:
C1:
tool: shell
inputs: ["input"]
outputs: ["output-1"]
args: cp input output-1
C2:
tool: shell
# A command which doesn't produce its output
outputs: ["output-2"]
args: true
C3:
tool: shell
inputs: ["output-2"]
outputs: ["output-2B"]
args: cp output-2 output-2B
C4:
tool: shell
inputs: ["output-1", "output-2B"]
outputs: ["output"]
args: cp output-1 output
|
