| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
When constructing module names, we normalize the directory path
implicit in it. However, we take the empty string as valid canonical
name for the top-level directory (as it is the empty relative path).
When accessing git roots, however, only the file-system canonical
path "." is special cased as self reference. Hence explicitly
convert the empty string.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... to the same limit as the values occuring in the stack.
|
|
... in error messages. The outer structure is usually more important
than the the details of the first element.
|
|
|
|
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.
|
|
|
|
|
|
So far, our serialisation and deserialisation assumed that no
node or result values are included contained in the given value.
However, for nodes (and hence ressults, given our implementation of
value nodes) there is a legitimate use case. An abstract interface
specification, given by provided nodes, can well be a meaningful
target to be exported. Implement serialisation for those values.
Also, avoid tree-unfolding the value when deserialising the value
by appropriately caching the corresponding expression pointers.
Moreover, avoid the quadratic overhead through linearly searching
through the list of artifacts.
|
|
|
|
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.
|
|
|
|
... by renaming HashGenerator to (incremental) Hasher and
dropping support for Git/MD5 hashes. The Hasher does not
expose the actual hash implementation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... and use it to replace the commonly used pattern in
Expression, LinkedMap, and GitTreeEntry. Furthermore, remove
assignment operators for Expression and LinkedMap as those
are considered to be used in an immutable manner anyway.
|
|
|
|
|
|
So that we can, also for header-only libraries, always declare the
direct dependencies without creating a cyclic dependency between
entity_name_data and expressions.
|
|
|
|
|
|
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.
|
|
Not only trees, but also regular files can disallow paths reaching
into them. If we have a file at a/b then another file at a/b/c
is a staging conflict as well. Make our tool recognize this.
|
|
... 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.
|
|
... as it will be required outside the target map.
|
|
|
|
The expected size of the list that defines the target was not checked
consistently. So, in case a target expected a list with 4 elements,
but got just 3, a segfault would happen.
This patch resolves this issue.
|
|
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.
|
|
DirectoryEntries must be constructed explicitly either via a GitTree*
or an unordered_map<string,ObjectType>. So, the case of an empty
directory, is represented by an empty map. Before this patch, empty
directories were represented by std::monostate and missing checks
on that led to a seg-fault.
|
|
For a user, an important information is to know which actions
are currently running and, more importantly, the target that
caused them. To do so, we need a bit of infrastructure.
- We have to keep track of begin and end of running actions,
as well as the order in which they were started. That has
to happen efficiently and in a thread-safe way.
- We have to compute and keep the origin map for actions,
even if we don't serialize the action graph.
|
|
... allowing to provide additional information in case of conflict
during flat staging.
|
|
To concatenate lists (the only ability the "+" operator had),
use "++".
|
|
|
|
For historic reasons, we considerd special strings as false values.
Drop that behavior in favor of a clean LISP-like semantics: everything
is true that is not empty.
|
|
|
|
... to foster the implementation of the built-in target "TREE"
|
|
... so remove it from the list of expected keys.
|
|
This patch introduces a templated ParseEntityName which can accept a
json or ExpressionPtr. Internally, performs a proper dispatch on these
cases
- isString
- isList
- size == 2
- size >= 3
A test is added for checking the proper handling of an empty list
|
