| Age | Commit message (Collapse) | Author |
|---|
|
...instead of std::optional<gsl::not_null<RepositoryConfig const*>>.
|
|
The build tool prints status messages at the end of each of the
major stages that sequentially follow each other. This allows,
in particular when using log files (that contain time stamps) to
quickly identify which phase was the resource consuming one. All
these message mention the (same!) configured target that is process
by this invocation of the build tool. In the presence of toolchains,
the configuration can, however, get quite large (containing lots of
paths to various tools). Therefore, shorted the configuration in the
repeated menions if it is very long (currenlty 320 characters); as
we do not change the first mentinoing ("Requested target is ..."),
even with that shortening the log contains the same information.
|
|
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.
|
|
...instead of not_null const ptr.
|
|
...instead of not_null const ptr.
|
|
|
|
|
|
|
|
|
|
|
|
...to properly fallback to local api if needed.
|
|
|
|
...and adjust interfaces.
|
|
...instead of initialization of the singleton.
Use builder for creation and validity check.
|
|
...and adjust interfaces.
|
|
...instead of using singleton calls.
|
|
...instead of using singleton calls.
|
|
...instead of using singleton calls.
|
|
...instead of using singleton calls.
|
|
|
|
...to track changes during refactoring easier.
|
|
...to track changes during refactoring easier.
|
|
|
|
... for failures instead of the binary strict_logging. In this
way, we can log at log level Error in the serve instance, and for
the client at level Warning or Info, depending on whether failure
is expected (i.e., if targets are potentially taken from a serve
endpoint) or not.
|
|
After successful build of an export target target a cache entry is
written. As those export targets have a dependency structure, care
is taken to write them in correct order.
Writing a cache entry for an export target requires knowledge of
the analysis result of that target. Originally, all targets used
to be analysed locally, so that information was available for
every target that was not read from the local target cache already.
However, with the introduction of serve endpoints, it can happen
that a target was analyzed locally, but it depends on targets
obtained from serve. In this case, we have to refrain from writing
a target-level cache entry to keep the the consistency invariants
of the target-level cache.
|
|
Once a RepositoryConfig instance gets populated, it must never be
changed again. Therefore, all functions accepting these instances
should only take them as pointers to const.
|
|
|
|
|
|
|
|
The gsl-lite implementation is slightly more picky in terms of
type conversions and constness resolution in initializers,
therefore small changes were needed.
|
|
... by taking the correct map to report which targets failed
to be analysed and also report about rules that failed to be
analysed.
|
|
Also updates the tests and all relevant documentation accordingly.
|
|
The result of the analysis is a JSON object containing the keys
`"artifacts"`, `"runfiles"`, and `"provides"`. This JSON object, by
default, is logged. However, it might be useful to process the data
contained in it, while, for example, developing new rules.
This patch adds a new command line option (`--dump-result`), reserved
to the subcommand `analyse`, to dump the analysis result to the given
file or stdout (if `-` is given).
|
|
... as also just describe can communicate to grpc endpoints.
|
|
... to simplify reuse.
|
|
... so that they are available in machine-readable form. In this
way, all logs can automatically be collected without the need of
parsing human-targeted error messages.
|
|
... in a structured way to eventually support machine-readable access to
the identifiers of the log files.
|
|
As `just serve` is used like a daemon it can be desirable to restrict
stderr, e.g., to only errors, while keeping a detailled log of the
activity in a file.
|
|
|
|
... to simplify set ups where configuration files are
provided as symbolic links to some central store.
|
|
|
|
|
|
|
|
Trees are first-class objects for justbuild. To allow interoperation
with other tools, it is necessary to provide those objects in a
standard format; for directories, those are archives. Hence procive
a corresponding option.
|
|
|
|
Main culprits:
- std::size_t, std::nullptr_t, and NULL require <cstddef>
- std::move and std::forward require <utility>
- unordered maps and sets require respective includes
- std::for_each and std::all_of require <algorithm>
|
|
For an absent export target, the first step of analysis is to ask
serve for the flexible variables. The answer to this request is,
however, independent of the configuration for this target. So we
can avoid calls by caching the answer in an additional map.
|
|
... so also report at info level if we got export targets served.
|
|
As just serve can simultaneously act as remote-execution endpoint,
it has to accept in its configuration all the necessary information,
in particular, the local launcher. Add it.
|
|
|
