TEST: arrow v18.0.0rc0 #1432
TEST: arrow v18.0.0rc0 #1432
Conversation
h-vetinari
requested review from
cpcloud,
jakirkham,
jreback,
kou,
kszucs,
leifwalsh,
nealrichardson,
pcmoritz,
pearu,
pitrou,
raulcd,
robertnishihara,
siddharthteotia,
wesm and
xhochy
as code owners
|
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
|
@conda-forge-admin, please rerender |
h-vetinari
changed the title
h-vetinari
force-pushed
the
e2e
branch
2 times, most recently
from
e1f9971 to
ea585c7
Compare
|
@conda-forge/arrow-cpp, happy to report that 17.0.0-rc0 is looking good from the POV of conda-forge. :) |
Cool! I had to create a second RC today due to a minor issue found |
h-vetinari
changed the title
|
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
h-vetinari
changed the title
MNT: Re-rendered with conda-build 24.7.1, conda-smithy 3.43.0, and conda-forge-pinning 2024.10.27.23.07.45
MNT: Re-rendered with conda-build 24.7.1, conda-smithy 3.43.0, and conda-forge-pinning 2024.10.27.23.07.45
…nda-forge-pinning 2024.10.27.23.07.45
h-vetinari
left a comment
h-vetinari
left a comment
There was a problem hiding this comment.
Thanks @jaimergp, looks like you found a way to fix things! I wanted to rerender because there's still a few things that are strange to me, mainly the contradictory definition of CONDA_BLD_PATH / MINIFORGE_HOME for windows, see below.
|
Ah, nevermind, CI never ran
I had run into the same issue previously... 😅 |
|
Oops, thanks for that fix with |
MNT: Re-rendered with conda-build 24.9.0, conda-smithy 3.43.1.dev12+g92312b51, and conda-forge-pinning 2024.10.29.12.41.35
…cross-compiling (#44507) ### Rationale for this change We can't use `find_package(gRPC)` and `gRPC::grpc_cpp_plugin` for cross-compiling because it's for host. We need `grpc_cpp_plugin` for target in cross-compiling. ### What changes are included in this PR? Add `ARROW_GRPC_CPP_PLUGIN` CMake option that overwrites `gRPC::grpc_cpp_plugin` path found by `find_package(gRPC)`. ### Are these changes tested? Yes. conda-forge/arrow-cpp-feedstock#1432 ### Are there any user-facing changes? Yes. * GitHub Issue: #44448 Authored-by: Sutou Kouhei <[email protected]> Signed-off-by: Sutou Kouhei <[email protected]>
|
Closing this one; will open a new PR for 19.0.0 to stop spamming people who participated here. |
…cross-compiling (#44507) ### Rationale for this change We can't use `find_package(gRPC)` and `gRPC::grpc_cpp_plugin` for cross-compiling because it's for host. We need `grpc_cpp_plugin` for target in cross-compiling. ### What changes are included in this PR? Add `ARROW_GRPC_CPP_PLUGIN` CMake option that overwrites `gRPC::grpc_cpp_plugin` path found by `find_package(gRPC)`. ### Are these changes tested? Yes. conda-forge/arrow-cpp-feedstock#1432 ### Are there any user-facing changes? Yes. * GitHub Issue: #44448 Authored-by: Sutou Kouhei <[email protected]> Signed-off-by: Sutou Kouhei <[email protected]>
4 participants
Some changes require testing across both libarrow and pyarrow; since we split off the pyarrow builds in a66c7c6, we'd need to publish a changed
libarrow, test the changes in pyarrow, and then potentially mark the builds as broken. In order to simplify this process, reintroduce some end-to-end testing here that can be used to do this all in one PR.