| Age | Commit message (Collapse) | Author |
|---|
|
In this way, we achieve that the target to be used by targets outside
this repository is the same, regardless if an unset TARGET_ARCH
is replaced by the value of ARCH. This is an assumption consuming
targets (legitimately) make and that was violated if one of those
configs is in target-level cache, but not the other.
|
|
|
|
|
|
|
|
While the built-in "configure" rule is forwarding the result of
the configured target, its own effective configuration is not that
of the configured target. The effective configuration is defined
to be that part of the incoming configuration that can potentially
influence the result of that target; in particular, this includes
variables read in defining the configuration transition.
|
|
... and thus allowing the "business logic" in the configuration
target (e.g., setting defaults and derived options) to be shared
by many targets.
|
|
|
|
Wrapt the default target in an export target, taking all effective
variables as flexible. Besides improved caching if just is used
as a dependency in a downstream project, this also improves
documentation as all configuration tunables are explicit and the
most important ones documented. In particular, the standard way of
getting information on a project, i.e., calling
just-mr describe
now gives proper information.
|
|
... when introducing export targets. In this way, the user
has a way to take a meaningful decission on which variables
to export.
|
|
Add an option --dump-vars showing the variables of the configuration
used (including the use of them being unset). This information can
be used, e.g., to export a given target in a maximally flexible way.
|
|
In this way, they can be more easily found using the standard
just-mr --main com_github_libgit2_libgit2 describe '' git2
instead of searching for the documentation file next to the
targets files in the import directory.
|
|
|
|
- specify explicitly for archives: for missing 'distfile' we use the basename of 'fetch_url'
- specify explicitly that 'subdir' is not a mandatory field
|
|
|
|
|
|
|
|
|
|
|
|
While building from source as certain advantages, there are also
good reasons to use pre-installed dependencies. Document this in the
tutorial to avoid wrong impressions readers might have otherwise.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... as this tool is usally used in conjunction with just; in
particular, our tutorial assumes just-mr to be present.
|
|
... in the overview table, especially as we recommend it when
building for host and manually setting CC and CXX.
|
|
This commit extends the test case for target-level cached artifacts
synchronization to include all locations of a target-cache entry where known
artifacts can be mentioned. These locations are the 'artifacts', 'runfiles',
and 'provides' map and all are considered now as part of the test.
|
|
Staging is quite a fundamental concept of just. Therefore, introduce
it early in the tutorial. In this way, it also becomes obvious, why
only targets are requested and files are not installed by default.
|
|
... as an way of directly obtaining an artifact without
an additional detour through the file system.
|
|
When the tutorial references blob identifiers in the output,
also immediately explain the syntax. Also emphasize the possible
abbreviations made possible by b9880e8ecdce02f047dfb1d19de5f1ed07a82ac6
given that they are typically used in practise.
Co-authored-by: Klaus Aehlig <aehlig@linta.de>
|
|
The test runner is supposed to report the reult in a file
called 'result' in the top-level action directory. However,
before starting the actual test, it changes the working
directory to the subdir 'work' where the input of the test
action is located. Therefore, when reporting the result,
the correct file name is '../result'. Fix this.
|
|
... in the same way, as we support different names for cc and c++.
|
|
|
|
|
|
|
|
|
|
|
|
... also in the first phases of the bootstrap procedure.
Co-authored-by: Oliver Reiche <oliver.reiche@huawei.com>
|
|
|
|
When constructing the build configuration for the bootstrap
build is just, start with the value of the environment variable
JUST_BUILD_CONF, if set, instead of the empty object. While there,
also propagate SOURCE_DATE_EPOCH from the environment to the build
configuration.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
