| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The value of --just option should be used as-is,
as it might be a var in PATH. The `execvp` call will handle this.
The Python script and man page have been updated accrodingly.
|
|
|
|
|
|
... given that binaries now only have "private-proto" (as there
are no public dependencies of a binary anyway). While there, also
hint on the script for git imports, to simplify the setup of
the example.
|
|
... on parts a first-time reader might (and actually did) stumble upon.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Compared to the previous commit, the action graphs for just
and its unit tests are unchanged.
- Git hash of action graph for ["",""]:
c6e75f17abd7ffaab6ff9bb725ad67ec0bf6c973
- Git hash of action graph for ["test/buildtool","TESTS"]:
8063dfb3dd7daa9ae01d95c177e14946f785c57e
Refactor:
- "local cflags" to "private-cflags"
- "local defines" to "private-defines"
- "link externals" to "private-ldflags"
- "deps" to "private-deps" for (test) binaries
- "proto" to "private-proto" for binaries
Improvements:
- consistent variable declaration order:
OS, ARCH, HOST_ARCH, TARGET_ARCH,
CC, CXX, CFLAGS, CXXFLAGS, ADD_CFLAGS, ADD_CXXFLAGS,
AR, ENV, PATH
- use fields close to their definition (in RULES)
- use common expression for binaries and test binaries
- split expression "flags" and "compiler"
... to separate ones for CC and CXX.
- rename "transition" to "deps-transition"
... to avoid conflicts with other transitions.
- support "defaults-transition" for CC expressions
Implement:
- "cflags" for libraries
- "private-cflags" for (test) binaries
- "private-defines" for test binaries
- "private-ldflags" for test binaries
- (public) "defines" for libraries
|
|
... in favor of the "tree" built-in rule.
|
|
... which is required for cross-compilation, e.g., clang's
`-target` option.
|
|
|
|
... so that for every construct supported in rules there is
an analogous one as a built-in rule to allow ad-hoc constructions
without having to write a rule (even though writing a rule is
recommended for everything occuring more than once):
- the "generic" rule allows an ad-hoc ACTION,
- the "file_gen" rule allows an ad-hoc BLOB,
- the "tree" rule allows an an ad-hoc TREE, and
- the "configure" rule allows an ad-hoc configuration transition.
|
|
The dependencies requested in order to read their "outs" or
"runfiles" also contribute to the effective configuration.
|
|
|
|
|
|
If norc options is given then no checks for the rc_path (e.g.,
whether it points to a file or not) should even be considered.
|
|
|
|
|
|
|
|
... assuming this repo already uses just and has a multi-repository
configuration committed. In the import, transitive dependencies, as
well as repositories serving as layers, are taken into account, and
"file" repositories are rewritten to be subdirs of the repository
imported. The imported repositories are renamed to reflect the
repository pulling them in, extending the name appropriately to
avoid conflicts. This renaming is reflected in the bindings and
layer references of the imported repositories as well.
In this simple version, no automatic deduplication of imported
repositories to already existing repositories is made, but the
user can specify that certain foreign repositories should not be
imported and mapped to already present repositories.
|
|
|
|
--main. Note that it works only if repo is a file repository
|
|
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.
|
|
|
