| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This code movement is required to break a cyclic dependency coming with the
introduction of the garbage collector. target_cache depends on
garbage_collector and garbage_collector would depend on target_cache to
determine the target-level-cache directory. After moving this calculation to a
more general location, the cycle is broken.
|
|
|
|
This usage of a different header file is required to break a cyclic dependency
coming with the introduction of the garbage collector. entity_name implicitly
depends on local_cas, which will get a new dependency to garbage_collector.
garbage_collector depends on target_cache_entry, which transitively depends on
entity_name. entity_name_data instead does not depend on local_cas and breaks
the cycle.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... to ensure unique readability even with file names containing
spaces or other special symbols; those kind of fancy file names
typically occur when a string intended as named target is implicitly
taken as a file (e.g., due to a spelling error). While there, also
include directory and repository in the error message.
|
|
Passing the logger by reference would require the caller to be
kept alive. Also, being a shared_ptr, the logger can be passed
by value at almost no cost.
|
|
... dumping only the configured targets that are export targets.
Those targets are of particular interest as those are the targets,
as they are the high-level caching points and also often serve
as interface between projects.
|
|
Make export targets identify themselves in the result_map,
so that we have accurate knowledge of the export targets
seen.
|
|
Allow in the addition of a target to the result map to indicate
that it was an export target; in this way, the information is
available as a result of the analysis.
|
|
Needed by the content-in-CAS git map to check fetched archives' checksums.
SHA1 and SHA256 hashers are already implemented.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Removed unused file_system_manager dependency
|
|
|
|
|
|
|
|
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
|
|
... 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.
|
|
|
|
|
|
... 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.
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
... if none is specified on command line or in the config.
|
|
|
