| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
... and remove it from the future design, as it is already implemented.
|
|
The "generic" rules deliberately resolves conflicts on identical
paths in a latest-wins fashion (seeing all artifacts as later than
all runfiles) to allow an easy way to define actions. However, the
inputs stage obtained by this resolution can still contain conflicts
and those are an error. Properly detect those. Also clarify in the
documentation, that only conflicts on identical paths are resolved
in the described priority, not semantic overlap.
|
|
... rather than as future design. While there, also add target-level
caching as a service to the list of documentation pages.
|
|
|
|
Originally, the expression lanuage only contained a function to
deduplicate a list, keeping only the right-most occurence. The
reason was that this is the order needed for linking: a library
providing an open symbol has to come on the command line after the
library using that symbol (and hence making it an open symbol).
However, by now use cases have emerged that require a topological
sorting where definition comes before use; also, when composing
the value of PATH from fragments, we usually want to keep the first
occurrence in order for it to take precedence. Therefore, also
add "nub_left" as built-in function, allowing a more condense (and
slightly more efficient) description in rules instead of the
revserse-nub_right-reverse pattern.
|
|
... allowing to select only the keys in a specific subdir,
and move the them to top-level.
|
|
|
|
|
|
|
|
|
|
|
|
Most built-in rules are just described by their name, assuming they
are known to the user anyway. One exception, however, are "export"
targets, as those serve as interfaces to (logical) repositories and
hence is supposed to have a documentation of the target itself. Over
time, however, "configure" targets have evolved to become internal
interfaces (maybe even for an external target), e.g., to provide
default values and hence make better use of the actual export target.
Therefore it is desirable to provide a bit more information when
asked to describe a "configure" target.
- As "configure" targets have a fixed set of keys, adding a "doc"
field is a conservative extension; this can be useful to give an
overview what the target is about.
- An important information of a "configure" target is the target
that is configured. While this, in general, is an expression, in
the typical cases, the description is very short (a literal target
name, or a variable). So we can afford to show the definition.
|
|
|
|
|
|
|
|
... and document the implementation in the concepts documentation.
|
|
|
|
While this can already be expressed by an "if" statement, having
a dedicated function for logical negation makes some expressions
more readable.
|
|
... using, also for the "then" branch, the empty list as default.
In this way, this statement not only more symmetric, but also
allows shorter representations of some typical expressions.
|
|
Lists are somtimes used in configurations as replacement for tuples.
Providing length gives an easy way to detect usage errors.
|
|
|
|
|
|
|
|
Numerical values are used at some places in justbuild: as value for
timeout scaling, as well as by the "range" expression that is used,
e.g., to define repreated test runs. Therefore, improve support
for numerical values by adding basic operations.
|
|
|
|
|
|
Adds documentation for the new proto requests required for the
'to_git' pragma root handling, as well as general syncing of root
trees. Also adds clarifying comments on handling of absent roots by
just-mr.
|
|
|
|
|
|
|
|
... as an overlay for the configuration, not the configuration
to be used for the target to configure.
|
|
|
|
|
|
...and reword content to move from proposal to implemented state.
|
|
|
|
While a foldl is enough to implement a reverse functionality,
adding it as a built in allows doing so in linear time.
|
|
... to obtain from a list of strings a map with those entries
as keys and true as value. In this way, repeated membership tests
in lists can be implemented more efficiently.
|
|
|
|
We now allow restrictive use of upwards symbolic links when
importing filesystem directories and archives to git.
|
|
... but an implemented concept. Update the documentation accordingly.
|
|
Also link it in the README.
|
|
|
|
via a 'SYMLINK' constructor function. This works similarly to the
'FILE' construct, but the name given must point to a non-upwards
symlink and a symlink artifact is being generated from it.
Also updates the relevant tests.
|
|
|
|
|
|
Co-authored-by: Sascha Roloff <sascha.roloff@huawei.com>
|
