| Age | Commit message (Collapse) | Author |
|---|
|
While there, also make sure we run unit tests that honor
TEST_COMPATIBLE_REMOTE in both configurations.
|
|
|
|
|
|
Include in the profile also the effective remote-execution endpoint,
properties, and dispatch list. Software projects are often tested
in a variety of environments or hardware configurations; as,
obviously, the performance might differ significantly (especially
depending on the used hardware) a proper analysis therefore requires
the possibility to distinguish the various backends. Adding the
effective configuration adds this posibility.
|
|
|
|
... in the summary, so that the user knows what to expect when
looking into the details-environment.
|
|
|
|
So far, the configuration variable TEST_BOOTSTRAP_JUST_MR could be
used to decide whether to run the end-to-end tests with the compiled
version of just-mr or the python script, which is mainly used for
bootstrapping only. To have a more simple way of running all tests in
all relevant configurations, make this an internal variable and branch
on the possible values, similarly as we already do for the possible
values of TEST_COMPATIBLE_REMOTE.
|
|
As a configure target, it is supposed to describe the change in the configuration;
setting a parameter to itself has no effect.
|
|
With the introduction of new exit codes, the presentation of
an invocation was changed to refrain from showing actions in
abnormal case failure already during analysis phase. However
ca8fd841736ca65fa4292887052c78243512962a did not include the case of
a successful build into the cases of normal circumstances. Fix this.
|
|
|
|
|
|
|
|
|
|
|
|
... by the requested subcommand. In particular, do not set it for
pure analyse requests.
|
|
For a generic rule, it is an error if map union of various
inputs (overlayed in correct order) does not form a proper stage. To
implement this check properly, we first have to construct the map of
all inputs and only then perform the staging check and not do the check
with only the runfiles, as 5e104a526cf76fe75312d2fd288a3c88f506fb0a
accidentally did. Fix this.
|
|
This test ensures that the AsyncMap implementation of the tree-overlay
computation works as expected and properly prevents duplicated work when it
comes to the repeated computation of the same trees.
|
|
|
|
instead of ArtifactDigest
|
|
functions of the class
|
|
|
|
|
|
|
|
... if available. This can be useful, when presenting builds
that are mainly there to have artifacts available for manual
use.
|
|
|
|
|
|
When showing a tree, we have for each entry already a designated
file name. Use this, to offer direct dowload links for blobs with
the intended name.
|
|
With just-mr supporting a custom prefix to be shown at the beginning
of a logged invocation, users might be pointed to the web server very
early. Therefore, properly indicate if the invocation data is not yet
complete.
|
|
Allow to specify a custom string that is extended by the basename
of the logging directory, in case invocation logging is activated.
This can be used, e.g., to point to the user to service doing
something useful with the logged data (or simply presenting it in
a nicer form).
|
|
During execution, paths are relative to the working directory of the
action; however, in our representation, all paths are always relative
to the action root. Commit d65d711f844224dcf9215c52be8f69fd2885adfc
tried to change the reporing to our usual standard, however got
the direction wrong; fix this.
|
|
For many text files it is useful to read them directly in the browser.
However, many files that are better analysed by machines (like large
repository configurations) also come as plain-text files. Therefore,
always offer to download a file currently being viewed. Use the URL
scheme in such a way that the name to download the file as can be
specified; in this way, we are prepared if we decide to also log
the artifacts to be built and offer those to be downloaded.
|
|
|
|
Being able to browse through past invocations of the build tool can
actually be useful and doing so in the browser is a way many users
prefer. Therefore, add a small WSGI application (written in python,
using werkzeug and jinja) serving a directory of invocation logs
via http.
|
|
|
|
|
|
Add the DWP variable to list of flexible_config. Also update the
documentation of the DEBUG variable.
While there, also fix a typo.
|
|
|
|
The "library" and "binary" rules are modified to generate, if
needed, the appropriate DWARF package from the DWARF objects of
their compilation units and the DWARF package files of their link
dependencies, if any. The resulting artifact is made available to
consumers in the provides map.
|
|
|
|
Allow the expressions running the actions producing the library and
binary artifacts to pass along more information to consumers if
needed by extending their return values to maps. Ensure the changes
do not affect other consumers of the current expressions, such as
the test rules, which do not expect extra information besides the
single action artifact.
|
|
...defining the DWARF format packaging tool to use once debug
fission is supported.
|
|
As the command passed to the linter can produce additional outputs
if debug fission is enabled, pass those artifact paths in a new
variable "extra outs", which the ["lint", "targets"] rule can then
make it available in the meta.json file expected by the linter.
|
|
For this purpose, the DEBUG configuration variable is updated to
expect a map with at least the USE_DEBUG_FISSION flag field. If
set, compilation of source files is expected to produce besides the
regular object file also a DWARF file.
|
|
...to reflect the value change from boolean to map.
Behavior of the proto rules remains the same, as only the truth
value of the variable is currently being taken into account.
|
|
It expects now the key 'USE_DEBUG_FISSION', which enables debug
fission, but does not add any flags on its own. For this, the
'FISSION_CONFIG' key is expected with certain entries that provide
the compile and/or link flags that configure debug fission.
The flags are added only where needed, i.e., before running or
storing the respective compile or link actions.
|
|
...if no flags are otherwise configured (by toolchain or
rule-specific configuration variables).
|
|
If in debug mode
- DEBUGFLAGS replaces any resulting CFLAGS and CXXFLAGS, and
- ADD_DEBUGFLAGS is appended to the resulting debug compile flags.
|
|
|
|
In preparation for the rule changes, to avoid introducing false
positives during future bisections.
|
