| Age | Commit message (Collapse) | Author |
|---|
|
As a library, that target depends implicitly on the toolchain,
hence the already present export of "TOOLCHAIN_CONFIG", but also
the environment for using that toolchain. So, export "ENV" as well.
|
|
... so that they can be served and hence the corresponding
dependency can be absent.
|
|
The latest remote execution protocol version includes a blob splicing RPC and
allows for the negotiation of the used chunking algorithm between client and
server.
|
|
... of all produced binaries, including the intermediate
ones: protoc and grpc_cpp_plugin.
|
|
... glibc provides synchronization stubs for single-threaded
environments as weak symobls. When linking pthreads, these
weak symbols must be replaced by the strong symbols provided
by the pthread library. For dynamically linking pthreads,
this is done automatically. However, to support this for
static linking, we must ensure to link the whole archive.
|
|
As we patch that API, it also can implicitly depend on the
toolchain (and hence its config), if we use a compiled implementation
of patch. Making the TOOLCHAIN_CONFIG a flexible part of the config
allow to, again, build static binaries as usual.
|
|
|
|
... as it is used by various libaries that are exported independently.
|
|
The source archive of grp contains upwards symlinks (that do not
point outside the source directory). For a normal build this is
not an issue; we still can generate a git tree from this archive
and the parts we use of this archive never even touch a directory
containing an upwards symlink.
However, when just-mr desires to get this root from a just serve
instance, the tree would have to be synced to the remote-execution CAS
and hence the restriction applies that we only consider non-upwards
relative symlinks as first-class citizens.
Therefore, ignore all symlinks in this archive and this way, without
changing the actual build, obtain an easy-to-manage root.
|
|
... to allow target-level caching.
|
|
... as it is part of just-mr, which is an essential part of
the build system installation by now.
|
|
|
|
This is brought in by the tree-of-archive rpc of just serve.
Also adds lzma and bzip2 as transitive dependencies.
|
|
|
|
Initial version, to be extended later with other RPCs.
|
|
|
|
... in particular options like '-Wno-array-parameter', which
are needed to silence newer compilers are not supported by
older ones. Hence, add '-Wno-unknown-warning-option' for all.
|
|
... to improve portability
|
|
|
|
|
|
Old K&R function definitions got cleaned upstream, which removes
many warnings when building zlib with more recent compilers.
|
|
... by disabling auto-configuration. The problem that the result
of this auto-configuration depends on the language standard used
and may (and in case of libproto does) leak into public interfaces
of consuming libraries; this would require every user of a library
with a public dependency of absl to use the same language standard
that library was built with. Such a requirement makes the rules
hard to use in a portable way.
|
|
... and use "linux" as default for OS. If TARGET_ARCH is
"arm" or not set, link against -latomic (for required
targets).
|
|
|
|
... to pass along toolchain settings for current and future
toolchain definitions. Configuration variable
COMPILER_FAMILY is replaced by TOOLCHAIN_CONFIG["FAMILY"].
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Due to a possible clang issue, protobuf v23.4 fails on debian-12
built with c++20. As such, protobuf and its consumer grpc have
been set to build with c++17 until this is resolved upstream.
Co-authored: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
|
|
This corresponds to the highest current version found in popular
distros (in this case, the one in Arch Linux).
The abseil library is now a dependency of protobuf (for logging).
|
|
Also adds the extra targets needed by protobuf v23.4, which now has
a dependency on abseil, and by grpc v1.56.2.
|
|
|
|
|
|
In preparation for the introduction of our blob splitting protocol as extension
to the remote execution api, we need to update the used remote execution api to
a more recent version than v2.0.0. Since no new tags are available right now,
we update to the preliminary protocol version v2.3 according to the following
discussion: https://github.com/bazelbuild/remote-apis/issues/253
|
|
|
|
|
|
... as this would result in cares used in a different configuration,
causing conflicts if cares is used directly.
|
|
... by making variables `os` and `arch` accessible to
bootstrap hints. Furthermore, support the hints `os_map`
and `arch_map` for mapping Justbuild's OS/ARCH to the
terminology used by the repository. Values not covered by
these maps will be passed through.
|
|
|
|
... as they could contain run-libs.
|
|
This allows better separation and, in particular, repositories
needed only for tests do not have to be provided for building the
tools. This also better documents which dependencies are only needed
for testing.
|
|
Justbuild does not directly depend on re2, hence the indirect
dependency on re2 is taken care of by pkg-config. Nevertheless, it
is useful to have such a file for packaging that takes most of the
dependencies from the system, but uses some of the dependencies
bundled; a particular such use case is taking the bundled versions
of proto, grpc, and absl, as those might be packaged in an
incompatible version.
|
|
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.
|
|
...missed so far. These are not actionable from our side.
|
