| ... |
... |
@@ -27,17 +27,17 @@ are the loaded representation of the ``.bst`` files loaded from the :ref:`projec |
|
27
|
27
|
The *Element* is an abstract base class which cannot do anything on its own, its
|
|
28
|
28
|
concrete class is defined by *plugins* which are either included in the BuildStream
|
|
29
|
29
|
:ref:`core set of plugins <plugins>` or loaded from external sources :ref:`defined by the project
|
|
30
|
|
-<project_plugins>`
|
|
|
30
|
+<project_plugins>`.
|
|
31
|
31
|
|
|
32
|
32
|
The responsibilities of an element include:
|
|
33
|
33
|
|
|
34
|
|
-* Loading the element's configuration from the core provided dictionary
|
|
|
34
|
+* Loading the element's configuration from the core provided dictionary.
|
|
35
|
35
|
* Providing a unique key for any element specific configuration which might
|
|
36
|
|
- effect the output produced by the element
|
|
37
|
|
-* Configuring the sandbox
|
|
|
36
|
+ affect the output produced by the element.
|
|
|
37
|
+* Configuring the sandbox.
|
|
38
|
38
|
* Staging the data into the sandbox, which might include Sources and
|
|
39
|
|
- the outputs of previous elements
|
|
40
|
|
-* Assembling the output *artifact*
|
|
|
39
|
+ the outputs of previous elements.
|
|
|
40
|
+* Assembling the output *artifact*.
|
|
41
|
41
|
|
|
42
|
42
|
|
|
43
|
43
|
Element data structure
|
| ... |
... |
@@ -72,9 +72,10 @@ deal of configurations understood by the *Element* is also understood by the cor |
|
72
|
72
|
has default configurations built into BuildStream and configurable with the project
|
|
73
|
73
|
configuration. These include values such as *variables*, *environment*, *sandbox*, etc.
|
|
74
|
74
|
|
|
75
|
|
-As shown above, composition is performed in two stages, as we only need to composite
|
|
76
|
|
-the data from the toplevel element declaration against the composition of previous
|
|
77
|
|
-stages every time we instantiate an element.
|
|
|
75
|
+As shown above, composition is performed in two stages for each element. First
|
|
|
76
|
+we compose everything below the line, this happens just once per 'kind' of
|
|
|
77
|
+element - the result is re-used. Secondly, we compose the element declaration
|
|
|
78
|
+on top.
|
|
78
|
79
|
|
|
79
|
80
|
|
|
80
|
81
|
Source
|
| ... |
... |
@@ -87,7 +88,7 @@ of the host or build environment. |
|
87
|
88
|
This is to say that:
|
|
88
|
89
|
|
|
89
|
90
|
* User configuration on the host, or filesystem outside of BuildStream designated
|
|
90
|
|
- directories, must never be modified as a side effect of running BuildStream.
|
|
|
91
|
+ directories, must never be modified as a side-effect of running BuildStream.
|
|
91
|
92
|
|
|
92
|
93
|
* When the Source uses host tools, host side configurations must never result in
|
|
93
|
94
|
deviations of what is staged to a build directory. The Source must behave exactly
|
| ... |
... |
@@ -95,12 +96,12 @@ This is to say that: |
|
95
|
96
|
|
|
96
|
97
|
The responsibilities of a source include:
|
|
97
|
98
|
|
|
98
|
|
-* Loading the source's configuration from the core provided dictionary
|
|
|
99
|
+* Loading the source's configuration from the core provided dictionary.
|
|
99
|
100
|
* Providing a unique key for any source specific configuration which might
|
|
100
|
|
- effect the staged source
|
|
101
|
|
-* Implement discovery of new versions of the source upstream (referred to as *"tracking"*)
|
|
102
|
|
-* Staging the unpacked source to a given directory
|
|
103
|
|
-* Preparing workspaces
|
|
|
101
|
+ affect the staged source.
|
|
|
102
|
+* Implement discovery of new versions of the source upstream (referred to as *"tracking"*).
|
|
|
103
|
+* Staging the unpacked source to a given directory.
|
|
|
104
|
+* Preparing workspaces.
|
|
104
|
105
|
|
|
105
|
106
|
|
|
106
|
107
|
Source data structure
|
