| Age | Commit message (Collapse) | Author |
|---|
|
Similarly to the proto compiler, this target is a third-party
binary and as such we do not care if it is built in release or
debug mode, so always clear the DEBUG flag.
|
|
As we only care about the result of proto targets, we do not care
if the proto compiler is built in release or debug mode, so always
clear the DEBUG flag for this binary.
|
|
...together with its dependencies:
- boringssl dec0d8f681348af8bb675e07bd89989665fca8bc
- protobuf v29.0
- abseil 20240722.0
Also update the bootstrap command for ssl to account for the fact
that now also the crypto library has fully moved to C++ and the
location of its sources has changed.
|
|
Update also direct dependencies:
- boringssl b8b3e6e
- google_apis fe8ba05
- protobuf v27.2
Also update the bootstrap build description for crypto library.
Remove ssl patch for gcc-14 build as fix is now in upstream.
Remove bytestream.proto patch as fix is now in upstream.
Target utf8_range now taken only from protobuf, where it is first
defined.
For now, upb dependencies in grpc still taken from its own
third_party subdirectory, as it is still kept synchronized with
the corresponding tree in the corresponding protobuf version.
|
|
|
|
|
|
|
|
- update boringssl to commit ae72a45
- update protobuf to v25.1
- update abseil to v20240116.0 (including patches)
Also add mirrors for third-party dependencies where known and
hashes correspond.
|
|
grpc is used in the toolchain defaults for proto servive libraries.
Still, it is typically built on its own, with its own toolchain,
flags, etc. Now, grpc, however has a public dependency on a the
rpc-status proto library, that the user may well use on their own,
however building in their own way which can yield conflicts. To solve
this, we hide the dependency on that proto library, as infrastructure
libs should not make assumptions on user-servicable libraries.
- First, we note that the dependency can be made a private one,
which already solves the conflict on header files (which will
essentially be the same, but might be defined in a different way).
- Next, we note that the library at linking basically only acts
as a default implementation; if the user provides their own
version of the rpc-status library, we should prefer that anyway.
As infrastructure is linked last, we have that default character
anyway; the only thing to do is to rename the library that no
staging conflict occurs.
|
|
This reverts commit 0db6f248a04f5a23102b4208c1f28b3633c6ef8a.
We have our own build description for lzma, hence we are likely not
affected by CVE-2024-3094. Nevertheless, we should not encourage the
use or distribution of an archive that contains a known backdoor.
Reverting this commit also points us to a mirror that is still
fetchable.
|
|
Now the curl URL API always fails to parse the empty string, so
our test was changed to reflect this.
|
|
|
|
Also updated the remote fetch repository, as the previous upstream
repository has since been archived.
|
|
... 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.
|
|
... to pass along toolchain settings for current and future
toolchain definitions. Configuration variable
COMPILER_FAMILY is replaced by TOOLCHAIN_CONFIG["FAMILY"].
|
|
|
|
|
|
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This update also removes upb as external dependency.
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
|
|
|
|
This is the last (and recommended) revision of minor v1.5.
|
|
tests have been updated accordingly
|
|
|
|
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")
|
|
|
|
|
|
|
|
|
|
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 far, we did not export ["@", "grpc", "", "grpc++_codegen_proto"]
and ["@", "grpc", "src/compiler", "grpc_cpp_plugin"]. Those targets
where used implicitly in the generation of protobuf. As flexible
config we use all variables those targets currently depend upon.
This will have to be extended once cross compilation will be
added. So far, the "TARGET_ARCH" is only used by targets that have
different source files (typically inline assembly) for different
target architectures. With cross compilation, also the tool chain
will depend on the target architecture.
|
|
|
|
The idea, as documented, of a header directory is to have a
directory, closed as a tree, owned by the respective library and
internally handled in an efficient way (as a single tree). If we
open up that directory, we just have staged data, and therefore
should treat it as such.
|
|
|
|
|
