Repository navigation
Conversation
|
|
|
@github-actions crossbow submit test-r-offline-vendored |
There was a problem hiding this comment.
🟡 Changes recommended
The build leaves rewritten checksums in tools/cpp/thirdparty/versions.txt, causing subsequent installs from the same source tree with upstream archives to fail checksum validation.
1 open issue
What changed in this PR
Enables more capable offline R source builds, including Parquet, by shipping trimmed third-party dependencies alongside the bundled Arrow C++ source.
Changes:
- Adds dependency caching, trimming, and upstream/vendored checksum tracking.
- Preserves optional features whose dependencies are available offline.
- Expands offline CI validation and records dependency licensing information.
| File | Description |
|---|---|
r/tools/vendor_dependencies.sh |
Downloads, caches, trims, and records checksums for vendored dependencies. |
r/tools/trim/boost.sh |
Retains the Boost libraries needed by R builds. |
r/tools/test-nixlibs.R |
Tests dependency selection, checksum rewriting, and offline feature handling. |
r/tools/nixlibs.R |
Selects compatible vendored archives and preserves supported offline features. |
r/inst/COPYRIGHTS |
Documents vendored dependency licenses and copyrights. |
r/DESCRIPTION |
References the copyright information. |
r/.Rbuildignore |
Excludes download caches and trimming scripts from source packages. |
r/.gitignore |
Ignores cached upstream archives. |
dev/tasks/tasks.yml |
Configures offline CI to exercise vendored dependencies and expected features. |
dev/release/rat_exclude_files.txt |
Excludes the copyright inventory from license-header checks. |
ci/scripts/r_test.sh |
Verifies expected build capabilities and allocator backends. |
Review effort: Balanced
|
Revision: dda15ba Submitted crossbow builds: ursacomputing/crossbow @ actions-7820f0a5a5
|
dda15ba to
5ad1f96
Compare
| -e NOT_CRAN=false | ||
| -e SKIP_VIGNETTES=true | ||
| -e ARROW_SOURCE_HOME='' | ||
| -e ARROW_WITH_BZ2=ON |
There was a problem hiding this comment.
I included bz2 here not because I think it's useful, but it's actually tiny (0.09MB). But we could save some bytes by removing it.
| @@ -0,0 +1,205 @@ | |||
| #!/usr/bin/env bash | |||
There was a problem hiding this comment.
I am mostly relying on the fact that our tests pass to confirm that this file is doing what we expect it to. But it does seem to work. If someone is interested in going over it with a fine(r) tooth comb, that would be appreciate, though given that it's part of our build system, I'm not sure that's required.
There was a problem hiding this comment.
🟡 Changes recommended
Critical issues remain: the trimmed Boost archive breaks bundled UBSan builds by excluding multiprecision, and persisted checksum rewrites cause subsequent builds using upstream archives to fail hash validation.
3 open issues
Review effort: Balanced
| # needs it uses this tarball, configuring libarrow fails in build_boost() | ||
| # because the boost_multiprecision target doesn't exist. | ||
| # - beast, variant, xpressive: only for ARROW_FLIGHT_SQL_ODBC. | ||
| EXCLUDED_LIBRARIES=(multiprecision beast variant xpressive) |
5ad1f96 to
11267e0
Compare
| # Returns the paths of the vendored tarballs that the libarrow source in | ||
| # `src_dir` can use, named by their ARROW_*_URL. | ||
| # The tarballs are trimmed, so the libarrow build only accepts them once | ||
| # `use_vendored_checksums()` has put their checksums in versions.txt. We only | ||
| # do that to the package's own copy of the source (tools/cpp), not e.g. ../cpp | ||
| # of a git checkout, and only for tarballs that were trimmed from the version | ||
| # that versions.txt pins (according to the checksums.txt file that | ||
| # tools/vendor_dependencies.sh writes). | ||
| usable_vendored_dependencies <- function(src_dir) { |
There was a problem hiding this comment.
Checking the vendored checksums is honestly a little bit silly — we compute them ourselves and include them with the package, so it's not really an independent verification (if someone wanted to make a change to them and distribute the source package, they could also just update the hash). But I do think it's ok to have as an integrity check or if we mess up something in our vendoring it'll fall back to downloading.
We also already do an integrity check when we download the dependencies before trimming.
|
I would love anyone's thoughts on this who has been tagged already, but I would especially love your thoughts on this @kou (and if this or the similar, but more far-reaching changes in #55492 would actually be better? It makes a much smaller tarball but with more to maintain and possible impacts for other C++ implementations) |
|
@github-actions crossbow submit test-r-linux-sanitizers test-r-m1-san |
|
Revision: 11267e0 Submitted crossbow builds: ursacomputing/crossbow @ actions-93b6ed324a
|
11267e0 to
e821d72
Compare
…ecs, compute and JSON Ship trimmed source tarballs of the thirdparty dependencies needed for Parquet, the compression codecs, RE2/utf8proc, JSON and mimalloc in the R package so that offline source builds (e.g. on CRAN) can include those features instead of falling back to a minimal build. Brotli and Zstandard aren't vendored (yet) to keep the package small, so offline builds turn them off. * tools/vendor_dependencies.sh (run by `make sync-cpp`) downloads, trims and vendors the tarballs into tools/vendored, and records each one's upstream and trimmed checksums in tools/vendored/checksums.txt. A dependency can provide its own trim script at tools/trim/<name>.sh. * When building the package's copy of the C++ source (tools/cpp), nixlibs.R uses the vendored tarballs that were trimmed from the versions that versions.txt pins, replacing their checksums in versions.txt with the trimmed ones. When offline, it only turns off the features whose dependencies aren't vendored. * The offline CI job (now test-r-offline-vendored) checks that the expected features are available after the build. * Add inst/COPYRIGHTS listing the vendored dependencies' licenses. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…eeds The generic trim leaves a 29 MB Boost tarball. tools/trim/boost.sh keeps only the Boost libraries that build_boost() in ThirdpartyToolchain.cmake includes (minus ones the R build doesn't use, e.g. multiprecision) and their dependencies, as resolved by Boost's own CMake, and drops their tests, docs and examples. This brings the vendored Boost down to ~5 MB. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
e821d72 to
d70832b
Compare
|
@github-actions crossbow submit test-r-linux-sanitizers test-r-m1-san |
|
Revision: d70832b Submitted crossbow builds: ursacomputing/crossbow @ actions-c59b7f870a
|
| # Some of them are required even for a minimal build, so they can't be turned | ||
| # off like the ones above. | ||
| env_var_list <- with_vendored_dependencies(env_var_list, vendored) | ||
| original_versions <- use_vendored_checksums(src_dir, env_var_list, vendored) |
There was a problem hiding this comment.
We can add support for changing ARROW_XXX_BUILD_SHA256_CHECKSUM by environment variables in cpp/ like we did for ARROW_XXX_URL. For example, we can change ARROW_XSIMD_URL by an environment variable:
arrow/cpp/cmake_modules/ThirdpartyToolchain.cmake
Lines 847 to 848 in 7eb865c
There was a problem hiding this comment.
Oh, yes that's nice. I'll do that + update here.
There was a problem hiding this comment.
🔵 Needs a closer look
The generated trimmed dependency archives are absent, so confirming that host-determined pruning preserves platform-specific build inputs requires human review of offline source-build results across supported platforms.
Review effort: Balanced


Rationale for this change
Vendor (and trim) C++ dependencies for offline builds that would allow us to build Parquet even when CMake cannot reach the internet. This is an R-package-only change, but in doing so can't trim quite as much (specifically building thrift without boost). The resulting tarball is larger than strictly necessary (~13.1 MB).
Resolves #55478
What changes are included in this PR?
Scripts for vendoring and trimming dependencies, tests
Are these changes tested?
Yes
Are there any user-facing changes?
More full-feature arrow builds
Was AI used for this PR?
In accordance to the AI generation guidelines, please disclose below whether and how AI was used in this PR.
PR code and description written by:
Reviewed before submission by: