| Age | Commit message (Collapse) | Author |
|---|
|
In commit da17ef5b04815ea3c6605274141a2e2b3b53b217, boringssl
was (among other dependencies) updated. Due to this updated, ["",
"crytpo-lib"] became a C++ library instead of a C one. Therefore,
the variables governing C++ compilation should be flexible as well.
|
|
|
|
Given the just added json-file formatter, we can generate a diff
formatting properly all json files, i.e., all target, rules, and
expression files, by applying that formatter to every target file
and combining the patches. A target description doing precisely
this can easily be obtained as computed root. In this way, we also
make good use of caching. To avoid doing recomputing the target
description unnecessarily, we factor through the tree structure of
the repository tree; the latter, we obtain from the to-git view of
the top-level directory, whereas for computing the diff we use the
actual (not necessarily committed) files.
|
|
|
|
Remove the test tainting of the distfiles target used in the large
tests and instead make an export target, as it is purely a source
tree. In this way, the distfiles tree can be truly absent and the
large tests can now also be delegated to the serve endpoint.
|
|
... using the already-committed configuration file and the
version of clang-tidy that was imported from the toolchain.
|
|
... and make it available to a new "lint" repository. In this way,
there is no dependency of the main or test repository on the newly
importet toolchain, while the "lint" repository has access to a
well-defined version of clang-tidy.
|
|
|
|
|
|
... as this contains a bug fix with respect to the currently-used version
1.70.1, see release notes https://github.com/grpc/grpc/releases/tag/v1.70.2
|
|
|
|
While for included libraries, it makes sense to have them with debug
symbols (after all, they are linked into a binary depending on it),
the toolchain binaries are just called, so there is no point in
building debug versions thereof.
|
|
Similarly to other third-party binaries, we should not care if they
are built in release or debug mode and as such we explicitly clear
the DEBUG flag.
|
|
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.
|
|
... as this library is used by different export targets.
|
|
...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.
|
|
... to allow reproducible debug builds. Unfortunately, gcc does not support
such an option.
|
|
|
|
|
|
Those are trivial dependency updates without the need to
change the build description. The new versions now are
- fmt 11.0.2
- cli11 2.4.2
- zlib 1.3.1
|
|
|
|
... inheriting path from CC and shell defaults.
|
|
|
|
... as the default summarizer can make good use of that,
if provided.
|
|
|
|
|
|
... which is needed until this is merged:
https://boringssl-review.googlesource.com/c/boringssl/+/68227
|
|
... to simplify definition.
|
|
|
|
... that is no longer used since d762bfa1953933dfac0a29a74523c25719396b8c
|
|
|
|
- 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.
|
|
As we use chunking also for reducing storage, we have to consider
the overhead of block devices which is in the order of kB per file.
So our target chunk size should be at least 2 orders of magnitude
above this. This suggests to minimally aim for a chunk size of
128kB, a target size that also has the advantage the that maximal
chunk size associated with this size is 1MB which is still well
below the maximal transmission size of grpc allowing us to avoid
the streaming API.
As we're scaling everything up by a factor of 16, we also have
to increase the number of bits in the involved masks by 4. We use
this to also extend the window size by using the 2 most significant
octets. Following the advice of the paper proposing FastCDC to
spread out the ones roughly equally suggests 0x4444 as a suitable
value for the two most significant octets.
We also change the suggested extension of the remote-execution API
accordingly. As the precise parameters for FastCDC when announced
over the remote-execution APIs are still under discussion upstream,
we simplify the name to not mention the target size.
|
|
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.
|
|
... and not directly used by our tool.
|
|
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.
|
|
Also updates the test-mixed-bootstrap script which must use the
explicit library version.
|
|
|
|
|
