| Age | Commit message (Collapse) | Author |
|---|
|
|
|
... and thus allowing the "business logic" in the configuration
target (e.g., setting defaults and derived options) to be shared
by many targets.
|
|
... when introducing export targets. In this way, the user
has a way to take a meaningful decission on which variables
to export.
|
|
While building from source as certain advantages, there are also
good reasons to use pre-installed dependencies. Document this in the
tutorial to avoid wrong impressions readers might have otherwise.
|
|
|
|
Staging is quite a fundamental concept of just. Therefore, introduce
it early in the tutorial. In this way, it also becomes obvious, why
only targets are requested and files are not installed by default.
|
|
... as an way of directly obtaining an artifact without
an additional detour through the file system.
|
|
When the tutorial references blob identifiers in the output,
also immediately explain the syntax. Also emphasize the possible
abbreviations made possible by b9880e8ecdce02f047dfb1d19de5f1ed07a82ac6
given that they are typically used in practise.
Co-authored-by: Klaus Aehlig <aehlig@linta.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... by explaining how to install the test binary and manually interact
with it. This also shows how to inspect an action for debugging.
|
|
... emphasizing that it constructs only a single artifact. In
this way, we avoid confusion with globs (that are introduced
later).
|
|
|
|
|
|
|
|
|
|
Like file or tree references, globs are restricted to the current
module; in fact, by the way we evaluate them, even to the top-level
directory of that module: a glob is a target having as artifacts and
runfiles those entries of the top-level directory of the specified
module that match the given pattern.
|
|
Co-authored-by: Alberto Sartori <alberto.sartori@huawei.com>
|
|
|
|
While there, fix a few typos in the same document as well.
|
|
Before this patch, the built-in "generic" type allowed for just output
files, listed in the field "outs". Now, the type also supports output
directories, listed in the "out_dirs" field. The output directories
are created before the command is executed.
|
|
|
|
|
|
|
|
In our semantics, it was always intended that names are completely
opaque and only used by passing them to functions providing
information about a target. However, we never enforced that they not
be compared for equality, even though we always had this in mind,
and the computation of the target-level cache key was designed with
this semantics in mind. Enforce this restriction now.
|
|
|
|
While we assume the reader already knows what proto buffers are,
the tutorial introduces the concept of anonymous targets.
|
|
|
|
|
|
|
|
... to initially use rules' predefined defaults.
|
|
In the defining expression of a rule, the TREE function is also
available. Document this.
|
|
|
|
Add a function transforming a list into a map. In this way, artifacts
collected positionally in a list can easily be realized as a stage
used for input to an action or output of a target.
|
|
|
|
|
|
|
|
|
|
... and detect conflicts araising this way. Also normalize
the paths after staging them to the specified subdir.
|
|
Our maps serve two purposes: on the one hand, they can be a generic
key-value association with arbitrary strings as keys. On the other
hand, we use them to describe arrangements of files (inputs to actions,
artifacts or runfiles generated). In this function, certain keys refer
to the same path and hence have to be identifed. Therefore, at places
where the keys clearly have to be paths in the file system, implicitly
normalize them and check for conflicts.
|
|
While there, also fix a few typos.
|
|
A complete documentation of a rule should not only include how to
use it (i.e., which fields are present and what is their meaning)
but also what the result is. This is particularly true, as the result
is structured and can contain some complex logic or conventions in
the provided information.
|
|
... allowing to provide additional information in case of conflict
during flat staging.
|
|
|
|
|
|
... that allow us to treat builds and tests in a uniform way, basically
by building a test report.
|
