| Age | Commit message (Collapse) | Author |
|---|
|
for just and just-mr within only one file
Co-authored-by: Oliver Reiche <oliver.reiche@huawei.com>
|
|
... with the order for "field_doc" being taken from
"string_fields", "target_fields", and "config_fields"
(in that order). For "config_doc", the order is taken
from the "config_vars" list. Thus, being consistent with
the (non-JSON) pretty printing of rules.
|
|
...and while there, avoid a bit of code duplication
|
|
|
|
|
|
The built-in rule configure carries out a full configuration
transition. While this is useful in quite a few situations,
care has to be taken to avoid conflicts on dependencies also
used in other ways by the calling target. Document this more
clearly in the documentation.
|
|
In our packaging of git2, do not carry out a configuration transition
that is visible to dependencies. While its dependencies, ssl and
zlib, accept that TARGET_ARCH is defaulted to ARCH if unset and
still return the same result, regardless which export targets are
cached, we still should not enforce any configuration transition on
dependencies as this has the potential to cause subtle conflicts.
The implicit default of TARGET_ARCH to ARCH in zlib and ssl can
stay, as those libraries do not depend on any other repositories.
|
|
While there, also add all direct dependencies explicitly; using
directly dependencies that are pulled in only indireclty causes
problems from a maintainability point of view.
|
|
i.e., libraries that are used only in the implementation without
use in the public header files. In this way, the set of headers
exposed to dependencies can be reduced leading potentially to better
incrementality.
|
|
|
|
And in this way avoid that two configuration differing only in an
unset TARGET_ARCH set to ARCH can be different due to one configration
being in target-level cache, but not the other.
|
|
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>
|
