| Age | Commit message (Collapse) | Author |
|---|
|
Using only our third-party descriptions, the build is independent of
PKG_CONFIG_PATH. However, when combinging our third-party descriptions
with dependencies taken from the system via pkg-config there is a
dependency of PKG_CONFIG_PATH due to those indirect dependencies.
Therefore, allow flexible PKG_CONFIG_PATH to support such a mixed
bootstrapping.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This update also removes upb as external dependency.
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
...as required by grpc v1.53.0
|
|
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
... and align lib names to commonly used pkg names.
|
|
... with two minor code base changes compared to previous
use of gsl-lite:
- dag.hpp: ActionNode::Ptr and ArtifactNode::Ptr are not
wrapped in gsl::not_null<> anymore, due to lack of support
for wrapping std::unique_ptr<>. More specifically, the
move constructor is missing, rendering it impossible to
use std::vector<>::emplace_back().
- utils/cpp/gsl.hpp: New header file added to implement the
macros ExpectsAudit() and EnsureAudit(), asserts running
only in debug builds, which were available in gsl-lite but
are missing in MS GSL.
|
|
|
|
... as the BUILD.bazel files that are the basis for the TARGETS
files seen to declare the dependencies in an incomplete way. Target
`grpc_base_c` needs `grpc_init()` and `grpc_shutdown()` from target
`grpc` (source `init.cc`). Adding this target dependency results
in a cycle.
This commit solves the issue by producing fewer but larger
libraries (as done in GRPC's CMakeLists.txt):
- `libgpr.a`: all gpr code
- `libgrpc.a`: all gprc code, depending on `libgpr.a`
- `libgrpc++.a`: all grpc++ code, depending on `libgrpc.a`
|
|
|
|
|
|
Major version release, with important fixes for our use-case.
|
|
This is the last (and recommended) revision of minor v1.5.
|
|
tests have been updated accordingly
|
|
|
|
|
|
google::longrunning::Operations::GetOperation
For each action that is executed, an entry is added to a shared thread
safe cache. Once the number of operations stored exceeds twice 2^n,
where n is given by the option --log-operations-threshold, at most 2^n
operations will be removed, in a FIFO scheme.
|
|
Co-authored-by: Sascha Roloff <sascha.roloff@huawei.com>
|
|
Main updates to build description:
- remove unused defines of type "HAVE_<lib>_H"
- add new variables that allow users to set explicitly the presence of some lib symbols
- replace most defines of type "HAVE_<lib>" with "USE_<lib>" (to match the flag names)
- added GLOBs (where it made sense) for increased maintainability
|
|
Changes in build description:
- fix capitalization of ENABLE_LIBGCC flag.
- add new HIDE_SYMBOLS flag to allow hiding of export symbols; used
similar logic as for libcurl to circumvent the original
CHECK_C_SOURCE_COMPILES macro use.
|
|
Changes to build description:
- new USE_SHA256 flag
- removed "Generic" option for USE_SHA1
- updated to the new source code structure
(split "src/git2" into "src/libgit2" and "src/util")
|
|
CXX libs
|
|
...as it is consumed by both grpc and libcurl. This makes sure
that both those libraries see the same ares target.
|
|
|
|
|
|
... which privately depends on pthreads.
|
|
Both ["", "ssl"] and ["", "crypto"] are targets of "boringssl"
that are intended for use outside this repository. Both depend on
the ["CC", "library"]-target ["", "crytpo-lib"], in fact even visibly,
as ssl has a library-dependency on the crypto library. Therefore,
we have to follow the standard export pattern that all uses of this
library go through the same (closest) export target. Fix this!
|
|
|
|
|
|
|
|
Removed superfluous "OS" env var
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
|
|
|
