@@ -13,16 +13,16 @@ in BXL may be challenging without much prior knowledge of Buck2 building blocks
13
13
### Build
14
14
15
15
You can build targets within BXL with
16
- [ ` ctx.build() ` ] ( ../../api/bxl/bxl/ Context/#bxl_ctxbuild ) . The result is a
17
- [ ` bxl.BuildResult ` ] ( ../../api/bxl/bxl/ BuildResult ) , which has ` artifacts() ` and
16
+ [ ` ctx.build() ` ] ( ../../api/bxl/Context/#contextbuild ) . The result is a
17
+ [ ` bxl.BuildResult ` ] ( ../../api/bxl/BuildResult ) , which has ` artifacts() ` and
18
18
` failures() ` functions that provide iterators to the artifacts or failures,
19
19
respectively. You can pass in a single target or target pattern to build.
20
20
21
21
### Analysis
22
22
23
23
You can run analysis on targets within BXL via
24
- [ ` ctx.analysis() ` ] ( ../../api/bxl/bxl/ Context/#bxl_ctxanalysis ) . Analysis means
25
- to evaluate the underlying rule implementation for the inputted targets, and
24
+ [ ` ctx.analysis() ` ] ( ../../api/bxl/Context/#contextanalysis ) . Analysis means to
25
+ evaluate the underlying rule implementation for the inputted targets, and
26
26
produce the providers that the rule defined for the target. A common workflow is
27
27
to inspect the resulting providers, and perhaps ensure parts of these providers
28
28
or run actions using information from the providers (see [ Actions] ( #actions )
@@ -34,12 +34,9 @@ Buck2 supports a couple different query types: querying the unconfigured graph
34
34
(` buck2 uquery ` ), the configured graph (` buck2 cquery ` ), or the action graph
35
35
(` buck2 aquery ` ). These queries are all available in BXL as well:
36
36
37
- - ` ctx.uquery() ` returns a
38
- [ ` bxl.UqueryContext ` ] ( ../../api/bxl/bxl/UqueryContext )
39
- - ` ctx.cquery() ` returns a
40
- [ ` bxl.CqueryContext ` ] ( ../../api/bxl/bxl/CqueryContext )
41
- - ` ctx.aquery() ` returns a
42
- [ ` bxl.AqueryContext ` ] ( ../../api/bxl/bxl/AqueryContext )
37
+ - ` ctx.uquery() ` returns a [ ` bxl.UqueryContext ` ] ( ../../api/bxl/UqueryContext )
38
+ - ` ctx.cquery() ` returns a [ ` bxl.CqueryContext ` ] ( ../../api/bxl/CqueryContext )
39
+ - ` ctx.aquery() ` returns a [ ` bxl.AqueryContext ` ] ( ../../api/bxl/AqueryContext )
43
40
44
41
You can read more about the individual queries in the API docs. There are many
45
42
queries that are common between uquery, cquery, and aquery, but cquery and
@@ -50,13 +47,13 @@ query that takes in the entire query as a string literal. A common use for
50
47
entire query string directly into ` eval() ` .
51
48
52
49
The query results are target sets (iterable container) of
53
- [ ` bxl.UnconfiguredTargetNode ` s] ( ../../api/bxl/bxl/ UnconfiguredTargetNode ) for
54
- uquery, [ ` bxl.ConfiguredTargetNode ` s] ( ../../api/bxl/bxl/ ConfiguredTargetNode )
55
- for cquery, and [ ` bxl.ActionQueryNode ` s] ( ../../api/bxl/bxl/ ActionQueryNode ) for
56
- aquery. Each of these node types have accessors on their attributes. A common
57
- workflow is to run some query in BXL, and iterate through the resulting nodes to
58
- inspect their attributes, and use those attributes to inform further
59
- computations in BXL.
50
+ [ ` bxl.UnconfiguredTargetNode ` s] ( ../../api/bxl/UnconfiguredTargetNode ) for
51
+ uquery, [ ` bxl.ConfiguredTargetNode ` s] ( ../../api/bxl/ConfiguredTargetNode ) for
52
+ cquery, and [ ` bxl.ActionQueryNode ` s] ( ../../api/bxl/ActionQueryNode ) for aquery.
53
+ Each of these node types have accessors on their attributes. A common workflow
54
+ is to run some query in BXL, and iterate through the resulting nodes to inspect
55
+ their attributes, and use those attributes to inform further computations in
56
+ BXL.
60
57
61
58
#### Uquery
62
59
@@ -84,8 +81,7 @@ You can create actions directly within the BXL API. The available action APIs
84
81
are equivalent to the ones found on the
85
82
[ ` AnalysisActions ` ] ( ../../api/build/AnalysisActions ) type for normal rules, with
86
83
the caveat that [ dynamic actions] ( ./bxl_dynamic_output.md ) use the
87
- [ ` bxl.Context ` ] ( ../../api/bxl/bxl/Context ) (which provides richer
88
- functionalities).
84
+ [ ` bxl.Context ` ] ( ../../api/bxl/Context ) (which provides richer functionalities).
89
85
90
86
A common workflow would be to run analysis on a target, and use some interesting
91
87
bits found in the analysis result to construct an augmented
@@ -98,13 +94,13 @@ output (see below for ensuring). Also see
98
94
Ensuring an artifact means that you want the artifact to be materialized
99
95
(meaning, downloaded to your machine) at the end of the BXL execution. There are
100
96
two APIs for ensuring: ` ctx.output.ensure() ` and ` ctx.output.ensure_multiple() `
101
- (see [ ` bxl.OutputStream ` ] ( ../../api/bxl/bxl/ OutputStream ) ). As the naming
102
- indicates, the former is for ensuring a single artifact, and the latter is for
103
- ensuring multiple artifact-like inputs. Artifact-like inputs include
97
+ (see [ ` bxl.OutputStream ` ] ( ../../api/bxl/OutputStream ) ). As the naming indicates,
98
+ the former is for ensuring a single artifact, and the latter is for ensuring
99
+ multiple artifact-like inputs. Artifact-like inputs include
104
100
[ ` cmd_args ` ] ( ../../api/build#cmd_args ) (can be found when inspecting providers),
105
- [ ` bxl.BuildResult ` ] ( ../../api/bxl/bxl/ BuildResult ) (produced when building
106
- something in BXL), or [ ` artifact ` ] ( ../../api/build/artifact ) (can be found when
107
- inspecting providers, or creating your own actions).
101
+ [ ` bxl.BuildResult ` ] ( ../../api/bxl/BuildResult ) (produced when building something
102
+ in BXL), or [ ` artifact ` ] ( ../../api/build/artifact ) (can be found when inspecting
103
+ providers, or creating your own actions).
108
104
109
105
A common workflow is to ensure an artifact that you created via some custom
110
106
actions defined in your script, or ensuring some artifacts found in the
0 commit comments