| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
End-to-end tests should, like all tests, be independent of any
non-project files the user has in their home directory. This also
applies when running the tests locally. In particular, end-to-end
tests should not read the user's ~/.just-mrrc. Therefore, properly
set --norc in all end-to-end tests (where this is not already
the case).
|
|
...when calling std::filesystem::weakly_canonical, since the latter converts the argument path to an absolute path internally.
|
|
|
|
|
|
|
|
In all presentations of actions to the user, we use output paths
relative to the root of the action directory. Therefore, we should
do the same in the profile. However, when noting the completion of
an action, we get paths as in the wire protocol, i.e., relative to
the working directory of the action. Therefore, rebase appropriately.
|
|
|
|
and while there, replace `auto` with explicit signatures.
|
|
|
|
|
|
|
|
We use a pointer to the actual Profile object to handle profiling,
if requested. For this to work, actual object needs to stay in
scope. However, we handle most of the operations, including parsing
of arguments, in a global try-catch block. In order to be able to
also correctly write a profile file outside this block, move the
scope of the Profile object to top-level in main.
While there, also improve the signature of the Profile class. That
class is only meaningful, if a profile should eventually be writting
to disk. So reflect this in the constructur. Also, once we know the
file name to write the profile to (if any), we have already parsed
the command line; so the making available of the command line to the
profile can be enforced by adding this to the constructor as well.
Co-authored-by: Denisov Maksim <denisov.maksim@huawei.com>
|
|
As parsing the the command-line is non-trivial, we include all the
relevant information about the command line in the profile. This
should also include the subcommand. For sake of completeness, we
also include the non-option arguments of the subcommand.
|
|
|
|
|
|
Extend the profile by including non-zero exit codes of individual
actions. When looking at an individual build invocation, the actions
with non-zero exit code are often the interesting ones, like root
cause of a build failure, or failing tests. Therefore, it is useful
information to include this information; by leaving out the exit
code if it is zero, we do not significantly increase the profile.
|
|
... under the advanced chapter of our tutorial.
|
|
While it is useful to have an end-to-end example also for advanced
topics, they should not be mixed with the basic tutorial showing
how to use the tool to build a typical project (here in C/C++).
|
|
... and ensure that pandoc processes them correctly. In particular,
add an empty line around itemize environments.
|
|
|
