ARROW-12175: [C++] Fix CMake packages #13892

kou · 2022-08-16T07:58:23Z

ARROW-9171 and ARROW-17231 are also fixed.

Our CMake packages are broken. For example, find_package(Parquet)
doesn't work without specifying CMAKE_MODULE_PATH.

find_package(${PACKAGE}) searches
${PREFIX}/${PACKAGE}/${PACKAGE}Config.cmake or
${PREFIX}/${PACKAGE}/Find${PACKAGE}.cmake. But our .cmake files are
always installed ${PREFIX}/arrow/. So find_package(Parquet) can't find
${PREFIX}/arrow/FindParquet.cmake because "/arrow/" isn't
"/${PACKAGE}".

This change fixes this by installing ${PACKAGE}Config.cmake to
${PREFIX}/${PACKAGE}/ instead of ${PREFIX}/arrow/.

This also removes all Find${PACKAGE}.cmake. We only provides
${PACKAGE}Config.cmake. Our Find${PACKAGE}.cmake can find ${PACKAGE}
by CMake, pkg-config or manual .so/.h search. But we don't need to
support pkg-config nor manual .so/.h search. We can use
${PACKAGE}Config.cmake to support CMake package search. So this
removes all Find${PACKAGE}.cmake.

This also introduces namespace to our CMake targets. For example,
arrow_shared is exported as Arrow::arrow_shared and
parquet_static is exported as Parquet::parquet_static. But no
namespace targets such as arrow_shared and parquet_static are
still also exported for keeping backward compatibility. But this
requires CMake 3.18 or later for users because add_library(ALIAS)
for non-global IMPORTED library is available since CMake 3.18.

(Plasma::plasma-store-server target is also added for
plasma-store-server executable.)

FYI: We can resolve this problem by using COMPONENTS feature of
find_package(). For example, find_package(Arrow COMPONENTS Parquet) is used instead of find_package(Parquet). With
COMPONENTS, ${PACKAGE} is always "Arrow". So we can still install
our .cmake files to ${PREFIX}/arrow/. But this approach breaks
backward compatibility. So I choose ${PREFIX}/${PACKAGE}/*.cmake
approach.

github-actions · 2022-08-16T08:12:28Z

https://issues.apache.org/jira/browse/ARROW-12175

github-actions · 2022-08-16T08:12:30Z

⚠️ Ticket has not been started in JIRA, please click 'Start Progress'.

kou · 2022-08-22T04:32:07Z

@github-actions crossbow submit -g nightly-tests -g nightly-packaging -g nightly-release

kou · 2022-08-22T06:49:43Z

@github-actions crossbow submit -g nightly-tests -g nightly-packaging -g nightly-release

kou · 2022-08-23T05:53:08Z

@github-actions crossbow submit example-python-minimal-build-ubuntu-venv homebrew-cpp verify-rc-source-python-linux-conda-latest-amd64 wheel-macos-big-sur-cp310-arm64 wheel-manylinux2014-cp310-amd64 wheel-windows-cp310-amd64

kou · 2022-08-24T00:09:29Z

@github-actions crossbow submit verify-rc-source-python-linux-conda-latest-amd64 wheel-windows-cp310-amd64

kou · 2022-08-24T05:19:07Z

@github-actions crossbow submit -g nightly-tests -g nightly-packaging -g nightly-release

kou · 2022-08-25T07:21:44Z

@github-actions crossbow submit -g nightly-tests -g nightly-packaging -g nightly-release

kou · 2022-08-26T15:35:14Z

@github-actions crossbow submit conda-linux-gcc-py310-cpu

kou · 2022-08-27T01:04:25Z

@github-actions crossbow submit conda-linux-gcc-py310-cpu

ARROW-9171 is also fixed. Our CMake packages are broken. For example, find_package(Parquet) doesn't work without specifying CMAKE_MODULE_PATH. find_package(${PACKAGE}) searches ${PREFIX}/${PACKAGE}/${PACKAGE}Config.cmake or ${PREFIX}/${PACKAGE}/Find${PACKAGE}.cmake. But our .cmake files are always installed ${PREFIX}/arrow/. So find_package(Parquet) can't find ${PREFIX}/arrow/FindParquet.cmake because "/arrow/" isn't "/${PACKAGE}". This change fixes this by installing ${PACKAGE}Config.cmake to ${PREFIX}/${PACKAGE}/ instead of ${PREFIX}/arrow/. This also removes all Find${PACKAGE}.cmake. We only provides ${PACKAGE}Config.cmake. Our Find${PACKAGE}.cmake can find ${PACKAGE} by CMake, pkg-config or manual .so/.h search. But we don't need to support pkg-config nor manual .so/.h search. We can use ${PACKAGE}Config.cmake to support CMake package search. So this removes all Find${PACKAGE}.cmake. This also introduces namespace to our CMake targets. For example, arrow_shared is exported as Arrow::arrow_shared and parquet_static is exported as Parquet::parquet_static. But no namespace targets such as arrow_shared and parquet_static are still also exported for keeping backward compatibility. But this requires CMake 3.11 or later for users because we can't use add_library(IMPORTED) is available since CMake 3.11. (Plasma::plasma-store-server target is also added for plasma-store-server executable.) FYI: We can resolve this problem by using COMPONENTS feature of find_package(). For example, find_package(Arrow COMPONENTS Parquet) is used instead of find_package(Parquet). With COMPONENTS, ${PACKAGE} is always "Arrow". So we can still install our .cmake files to ${PREFIX}/arrow/. But this approach breaks backward compatibility. So I choose ${PREFIX}/${PACKAGE}/*.cmake approach.

… isn't provided This is a follow-up of ARROW-12175 / apache#13892 . We introduced `${PACKAGE}::` namespace to all exported CMake targets such as `Arrow::arrow_shared` and `Arrow::arrow_static` but we also provides no namespaced CMake targets such as `arrow_share` and `arrow_static` as aliases of namespaced CMake targets. But the backward compatibility feature isn't worked for `_shared`.

ursabot · 2022-08-30T19:16:15Z

Benchmark runs are scheduled for baseline = b43c6f6 and contender = 93b63e8. 93b63e8 is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Finished ⬇️0.0% ⬆️0.0%] ec2-t3-xlarge-us-east-2
[Failed] test-mac-arm
[Failed ⬇️0.55% ⬆️0.0%] ursa-i9-9960x
[Finished ⬇️0.32% ⬆️0.0%] ursa-thinkcentre-m75q
Buildkite builds:
[Finished] 93b63e8f ec2-t3-xlarge-us-east-2
[Failed] 93b63e8f test-mac-arm
[Failed] 93b63e8f ursa-i9-9960x
[Finished] 93b63e8f ursa-thinkcentre-m75q
[Finished] b43c6f6b ec2-t3-xlarge-us-east-2
[Failed] b43c6f6b test-mac-arm
[Failed] b43c6f6b ursa-i9-9960x
[Finished] b43c6f6b ursa-thinkcentre-m75q
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

ursabot · 2022-08-30T19:17:03Z

['Python', 'R'] benchmarks have high level of regressions.
ursa-i9-9960x

… isn't provided (#14003) This is a follow-up of ARROW-12175 / #13892 . We introduced `${PACKAGE}::` namespace to all exported CMake targets such as `Arrow::arrow_shared` and `Arrow::arrow_static`, but we also provided no-namespaced CMake targets such as `arrow_shared` and `arrow_static` as aliases of namespaced CMake targets. However, the logic to provide `arrow_shared` was buggy. Authored-by: Sutou Kouhei <kou@clear-code.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

ARROW-9171 and ARROW-17231 are also fixed. Our CMake packages are broken. For example, `find_package(Parquet)` doesn't work without specifying `CMAKE_MODULE_PATH`. `find_package(${PACKAGE})` searches `${PREFIX}/${PACKAGE}/${PACKAGE}Config.cmake` or `${PREFIX}/${PACKAGE}/Find${PACKAGE}.cmake`. But our .cmake files are always installed `${PREFIX}/arrow/`. So `find_package(Parquet)` can't find `${PREFIX}/arrow/FindParquet.cmake` because "`/arrow/`" isn't "`/${PACKAGE}`". This change fixes this by installing `${PACKAGE}Config.cmake` to `${PREFIX}/${PACKAGE}/` instead of `${PREFIX}/arrow/`. This also removes all `Find${PACKAGE}.cmake`. We only provides `${PACKAGE}Config.cmake`. Our `Find${PACKAGE}.cmake` can find `${PACKAGE}` by CMake, pkg-config or manual .so/.h search. But we don't need to support pkg-config nor manual .so/.h search. We can use `${PACKAGE}Config.cmake` to support CMake package search. So this removes all `Find${PACKAGE}.cmake`. This also introduces namespace to our CMake targets. For example, `arrow_shared` is exported as `Arrow::arrow_shared` and `parquet_static` is exported as `Parquet::parquet_static`. But no namespace targets such as `arrow_shared` and `parquet_static` are still also exported for keeping backward compatibility. But this requires CMake 3.18 or later for users because `add_library(ALIAS)` for non-global `IMPORTED` library is available since CMake 3.18. (`Plasma::plasma-store-server` target is also added for `plasma-store-server` executable.) FYI: We can resolve this problem by using `COMPONENTS` feature of `find_package()`. For example, `find_package(Arrow COMPONENTS Parquet)` is used instead of `find_package(Parquet)`. With `COMPONENTS`, `${PACKAGE}` is always "Arrow". So we can still install our .cmake files to `${PREFIX}/arrow/`. But this approach breaks backward compatibility. So I choose `${PREFIX}/${PACKAGE}/*.cmake` approach. Authored-by: Sutou Kouhei <kou@clear-code.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

… isn't provided (apache#14003) This is a follow-up of ARROW-12175 / apache#13892 . We introduced `${PACKAGE}::` namespace to all exported CMake targets such as `Arrow::arrow_shared` and `Arrow::arrow_static`, but we also provided no-namespaced CMake targets such as `arrow_shared` and `arrow_static` as aliases of namespaced CMake targets. However, the logic to provide `arrow_shared` was buggy. Authored-by: Sutou Kouhei <kou@clear-code.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

jorisvandenbossche · 2022-09-06T11:21:09Z

cpp/cmake_modules/FindArrow.cmake

-  message(STATUS "Arrow version: ${ARROW_VERSION} (${ARROW_FIND_APPROACH})")
-  message(STATUS "Arrow SO and ABI version: ${ARROW_SO_VERSION}")
-  message(STATUS "Arrow full SO version: ${ARROW_FULL_SO_VERSION}")
-  message(STATUS "Found the Arrow core shared library: ${ARROW_SHARED_LIB}")
-  message(STATUS "Found the Arrow core import library: ${ARROW_IMPORT_LIB}")
-  message(STATUS "Found the Arrow core static library: ${ARROW_STATIC_LIB}")


If I understand correctly, this file is now replaced by cmake's find_package(Arrow) now using the ArrowConfig.cmake file that gets installed in the cmake directory (when installing Arrow C++).
But so before, the above printed some details about Arrow being found (and which version, the path, ..). Is there a way to let find_package(Arrow) still print this? (would adding that to ArrowConfig.cmake.in do this?)

Yes. We need to add message(STATUS ...) to ArrowConfig.cmake.in for it. cmake --debug-print prints more details but it will not show these information.

But *Config.cmake doesn't use message(STATUS ...) in general. If we want to add message(STATUS ...), it's better that we check Arrow_FIND_QUIETLY like the following:

if(NOT Arrow_FIND_QUIETLY) message(STATUS ...) endif()

Arrow_FIND_QUIETLY is TRUE only when an user specify QUIET explicitly like find_package(Arrow QUIET).

See also; https://cmake.org/cmake/help/latest/command/find_package.html#package-file-interface-variables

I've created https://issues.apache.org/jira/browse/ARROW-17632 to follow this up, feel free to update the ticket if I missed anything

Thanks @kou for the explanation and @raulcd for opening the JIRA!

jorisvandenbossche · 2022-09-06T11:22:56Z

python/pyarrow/src/CMakeLists.txt

@@ -59,7 +61,6 @@ endif()
 #

 find_package(Arrow REQUIRED)
-include(ArrowOptions)


For my own understanding, the reason this line is no longer needed, is because this will also be included by find_package(Arrow) already? (since ArrowConfig.cmake has a line include("${CMAKE_CURRENT_LIST_DIR}/ArrowOptions.cmake"))

…nd during build (#14059) This PR aims to add back `message(STATUS ...)` statements that printed some details about Arrow being found, its version, and the paths. These were refactored away as part of #13892. Authored-by: Dhruv Vats <dhruv25vats@gmail.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

…ckage (#14097) This is a follow up to update our build documentation from the changes on #13892 Authored-by: Raúl Cumplido <raulcumplido@gmail.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

ARROW-9171 and ARROW-17231 are also fixed. Our CMake packages are broken. For example, `find_package(Parquet)` doesn't work without specifying `CMAKE_MODULE_PATH`. `find_package(${PACKAGE})` searches `${PREFIX}/${PACKAGE}/${PACKAGE}Config.cmake` or `${PREFIX}/${PACKAGE}/Find${PACKAGE}.cmake`. But our .cmake files are always installed `${PREFIX}/arrow/`. So `find_package(Parquet)` can't find `${PREFIX}/arrow/FindParquet.cmake` because "`/arrow/`" isn't "`/${PACKAGE}`". This change fixes this by installing `${PACKAGE}Config.cmake` to `${PREFIX}/${PACKAGE}/` instead of `${PREFIX}/arrow/`. This also removes all `Find${PACKAGE}.cmake`. We only provides `${PACKAGE}Config.cmake`. Our `Find${PACKAGE}.cmake` can find `${PACKAGE}` by CMake, pkg-config or manual .so/.h search. But we don't need to support pkg-config nor manual .so/.h search. We can use `${PACKAGE}Config.cmake` to support CMake package search. So this removes all `Find${PACKAGE}.cmake`. This also introduces namespace to our CMake targets. For example, `arrow_shared` is exported as `Arrow::arrow_shared` and `parquet_static` is exported as `Parquet::parquet_static`. But no namespace targets such as `arrow_shared` and `parquet_static` are still also exported for keeping backward compatibility. But this requires CMake 3.18 or later for users because `add_library(ALIAS)` for non-global `IMPORTED` library is available since CMake 3.18. (`Plasma::plasma-store-server` target is also added for `plasma-store-server` executable.) FYI: We can resolve this problem by using `COMPONENTS` feature of `find_package()`. For example, `find_package(Arrow COMPONENTS Parquet)` is used instead of `find_package(Parquet)`. With `COMPONENTS`, `${PACKAGE}` is always "Arrow". So we can still install our .cmake files to `${PREFIX}/arrow/`. But this approach breaks backward compatibility. So I choose `${PREFIX}/${PACKAGE}/*.cmake` approach. Authored-by: Sutou Kouhei <kou@clear-code.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

… isn't provided (apache#14003) This is a follow-up of ARROW-12175 / apache#13892 . We introduced `${PACKAGE}::` namespace to all exported CMake targets such as `Arrow::arrow_shared` and `Arrow::arrow_static`, but we also provided no-namespaced CMake targets such as `arrow_shared` and `arrow_static` as aliases of namespaced CMake targets. However, the logic to provide `arrow_shared` was buggy. Authored-by: Sutou Kouhei <kou@clear-code.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

…nd during build (apache#14059) This PR aims to add back `message(STATUS ...)` statements that printed some details about Arrow being found, its version, and the paths. These were refactored away as part of apache#13892. Authored-by: Dhruv Vats <dhruv25vats@gmail.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

…ckage (apache#14097) This is a follow up to update our build documentation from the changes on apache#13892 Authored-by: Raúl Cumplido <raulcumplido@gmail.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

We need clang 11 or later for Gandiva. https://dev.azure.com/ursacomputing/crossbow/_build/results?buildId=37098&view=logs&j=4c86bc1b-1091-5192-4404-c74dfaad23e7&t=41795ef0-6501-5db4-3ad4-33c0cf085626&l=1001 [6/94] Generating decimal_ops.bc FAILED: src/gandiva/precompiled/decimal_ops.bc D:/bld/arrow-cpp-ext_1665469353844/work/cpp/build/src/gandiva/precompiled/decimal_ops.bc cmd.exe /C "cd /D D:\bld\arrow-cpp-ext_1665469353844\work\cpp\build\src\gandiva\precompiled && D:\bld\arrow-cpp-ext_1665469353844\_h_env\Library\bin\clang.exe -std=c++17 -fms-compatibility -fms-compatibility-version=19.20 -DGANDIVA_IR -DNDEBUG -DARROW_STATIC -DGANDIVA_STATIC -fno-use-cxa-atexit -emit-llvm -O3 -c D:/bld/arrow-cpp-ext_1665469353844/work/cpp/src/gandiva/precompiled/decimal_ops.cc -o D:/bld/arrow-cpp-ext_1665469353844/work/cpp/build/src/gandiva/precompiled/decimal_ops.bc -ID:/bld/arrow-cpp-ext_1665469353844/work/cpp/src -ID:/bld/arrow-cpp-ext_1665469353844/work/cpp/build/src -ID:/bld/arrow-cpp-ext_1665469353844/_h_env/Library/include" In file included from D:/bld/arrow-cpp-ext_1665469353844/work/cpp/src/gandiva/precompiled/decimal_ops.cc:20: In file included from D:/bld/arrow-cpp-ext_1665469353844/work/cpp/src\gandiva/precompiled/decimal_ops.h:20: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\cstdint:9: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\yvals_core.h:571:2: error: STL1000: Unexpected compiler version, expected Clang 11.0.0 or newer. #error STL1000: Unexpected compiler version, expected Clang 11.0.0 or newer. ^ This was added by me in apache#13892 but I can't remember why I pinned to 10...

…gs (#14376) We need clang 11 or later for Gandiva. https://dev.azure.com/ursacomputing/crossbow/_build/results?buildId=37098&view=logs&j=4c86bc1b-1091-5192-4404-c74dfaad23e7&t=41795ef0-6501-5db4-3ad4-33c0cf085626&l=1001 [6/94] Generating decimal_ops.bc FAILED: src/gandiva/precompiled/decimal_ops.bc D:/bld/arrow-cpp-ext_1665469353844/work/cpp/build/src/gandiva/precompiled/decimal_ops.bc cmd.exe /C "cd /D D:\bld\arrow-cpp-ext_1665469353844\work\cpp\build\src\gandiva\precompiled && D:\bld\arrow-cpp-ext_1665469353844\_h_env\Library\bin\clang.exe -std=c++17 -fms-compatibility -fms-compatibility-version=19.20 -DGANDIVA_IR -DNDEBUG -DARROW_STATIC -DGANDIVA_STATIC -fno-use-cxa-atexit -emit-llvm -O3 -c D:/bld/arrow-cpp-ext_1665469353844/work/cpp/src/gandiva/precompiled/decimal_ops.cc -o D:/bld/arrow-cpp-ext_1665469353844/work/cpp/build/src/gandiva/precompiled/decimal_ops.bc -ID:/bld/arrow-cpp-ext_1665469353844/work/cpp/src -ID:/bld/arrow-cpp-ext_1665469353844/work/cpp/build/src -ID:/bld/arrow-cpp-ext_1665469353844/_h_env/Library/include" In file included from D:/bld/arrow-cpp-ext_1665469353844/work/cpp/src/gandiva/precompiled/decimal_ops.cc:20: In file included from D:/bld/arrow-cpp-ext_1665469353844/work/cpp/src\gandiva/precompiled/decimal_ops.h:20: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\cstdint:9: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\yvals_core.h:571:2: error: STL1000: Unexpected compiler version, expected Clang 11.0.0 or newer. #error STL1000: Unexpected compiler version, expected Clang 11.0.0 or newer. ^ This was added by me in #13892 but I can't remember why I pinned to 10... Authored-by: Sutou Kouhei <kou@clear-code.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

ARROW-9171 and ARROW-17231 are also fixed. Our CMake packages are broken. For example, `find_package(Parquet)` doesn't work without specifying `CMAKE_MODULE_PATH`. `find_package(${PACKAGE})` searches `${PREFIX}/${PACKAGE}/${PACKAGE}Config.cmake` or `${PREFIX}/${PACKAGE}/Find${PACKAGE}.cmake`. But our .cmake files are always installed `${PREFIX}/arrow/`. So `find_package(Parquet)` can't find `${PREFIX}/arrow/FindParquet.cmake` because "`/arrow/`" isn't "`/${PACKAGE}`". This change fixes this by installing `${PACKAGE}Config.cmake` to `${PREFIX}/${PACKAGE}/` instead of `${PREFIX}/arrow/`. This also removes all `Find${PACKAGE}.cmake`. We only provides `${PACKAGE}Config.cmake`. Our `Find${PACKAGE}.cmake` can find `${PACKAGE}` by CMake, pkg-config or manual .so/.h search. But we don't need to support pkg-config nor manual .so/.h search. We can use `${PACKAGE}Config.cmake` to support CMake package search. So this removes all `Find${PACKAGE}.cmake`. This also introduces namespace to our CMake targets. For example, `arrow_shared` is exported as `Arrow::arrow_shared` and `parquet_static` is exported as `Parquet::parquet_static`. But no namespace targets such as `arrow_shared` and `parquet_static` are still also exported for keeping backward compatibility. But this requires CMake 3.18 or later for users because `add_library(ALIAS)` for non-global `IMPORTED` library is available since CMake 3.18. (`Plasma::plasma-store-server` target is also added for `plasma-store-server` executable.) FYI: We can resolve this problem by using `COMPONENTS` feature of `find_package()`. For example, `find_package(Arrow COMPONENTS Parquet)` is used instead of `find_package(Parquet)`. With `COMPONENTS`, `${PACKAGE}` is always "Arrow". So we can still install our .cmake files to `${PREFIX}/arrow/`. But this approach breaks backward compatibility. So I choose `${PREFIX}/${PACKAGE}/*.cmake` approach. Authored-by: Sutou Kouhei <kou@clear-code.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

… isn't provided (apache#14003) This is a follow-up of ARROW-12175 / apache#13892 . We introduced `${PACKAGE}::` namespace to all exported CMake targets such as `Arrow::arrow_shared` and `Arrow::arrow_static`, but we also provided no-namespaced CMake targets such as `arrow_shared` and `arrow_static` as aliases of namespaced CMake targets. However, the logic to provide `arrow_shared` was buggy. Authored-by: Sutou Kouhei <kou@clear-code.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

…nd during build (apache#14059) This PR aims to add back `message(STATUS ...)` statements that printed some details about Arrow being found, its version, and the paths. These were refactored away as part of apache#13892. Authored-by: Dhruv Vats <dhruv25vats@gmail.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

…ckage (apache#14097) This is a follow up to update our build documentation from the changes on apache#13892 Authored-by: Raúl Cumplido <raulcumplido@gmail.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

kou mentioned this pull request Aug 16, 2022

ARROW-17231: [C++] Restore STATIC_INSTALL_INTERFACE_LIBS for arrow_static #13707

Closed

github-actions bot added Component: FlightRPC Component: C++ - Gandiva Component: C++ Component: Parquet labels Aug 16, 2022

kou force-pushed the cpp-cmake-package branch 2 times, most recently from 38ee685 to 40e2e9d Compare August 17, 2022 01:06

github-actions bot added Component: Python Component: R labels Aug 17, 2022

This comment was marked as outdated.

Sign in to view

kou force-pushed the cpp-cmake-package branch from f2fd6ee to 119c8e1 Compare August 24, 2022 05:18

This comment was marked as outdated.

Sign in to view

kou force-pushed the cpp-cmake-package branch from 119c8e1 to c0d38cb Compare August 25, 2022 07:21

This comment was marked as outdated.

Sign in to view

kou deleted the cpp-cmake-package branch August 30, 2022 04:57

kou mentioned this pull request Aug 30, 2022

ARROW-17565: [C++] Backward compatible ${PACKAGE}_shared CMake target isn't provided #14003

Merged

jorisvandenbossche reviewed Sep 6, 2022

View reviewed changes

dhruv9vats mentioned this pull request Sep 7, 2022

ARROW-17632: [Python][C++] Add details of where libarrow is being found during build #14059

Merged

raulcd mentioned this pull request Sep 12, 2022

ARROW-17575: [Docs][C++] Update build document to follow new CMake package #14097

Merged

h-vetinari mentioned this pull request Sep 14, 2022

ARROW-17635: [Python][CI] Sync conda recipe with the arrow-cpp feedstock #14102

Merged

kou mentioned this pull request Oct 11, 2022

ARROW-17992: [CI][C++][Conda] Remove needless clangdev/llvmdev pinnings #14376

Merged

piotrwendykier mentioned this pull request Dec 1, 2022

[C++] CMake config files for Dataset are not copied to the install directory #14801

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ARROW-12175: [C++] Fix CMake packages #13892

ARROW-12175: [C++] Fix CMake packages #13892

kou commented Aug 16, 2022 •

edited

Loading

github-actions bot commented Aug 16, 2022

github-actions bot commented Aug 16, 2022

kou commented Aug 22, 2022

This comment was marked as outdated.

kou commented Aug 22, 2022

This comment was marked as outdated.

kou commented Aug 23, 2022

This comment was marked as outdated.

kou commented Aug 24, 2022

This comment was marked as outdated.

kou commented Aug 24, 2022

This comment was marked as outdated.

kou commented Aug 25, 2022

This comment was marked as outdated.

kou commented Aug 26, 2022

This comment was marked as outdated.

kou commented Aug 27, 2022

This comment was marked as outdated.

ursabot commented Aug 30, 2022

ursabot commented Aug 30, 2022

jorisvandenbossche Sep 6, 2022

kou Sep 6, 2022

raulcd Sep 6, 2022

jorisvandenbossche Sep 6, 2022

jorisvandenbossche Sep 6, 2022

kou Sep 6, 2022

ARROW-12175: [C++] Fix CMake packages #13892

ARROW-12175: [C++] Fix CMake packages #13892

Conversation

kou commented Aug 16, 2022 • edited Loading

github-actions bot commented Aug 16, 2022

github-actions bot commented Aug 16, 2022

kou commented Aug 22, 2022

This comment was marked as outdated.

kou commented Aug 22, 2022

This comment was marked as outdated.

kou commented Aug 23, 2022

This comment was marked as outdated.

kou commented Aug 24, 2022

This comment was marked as outdated.

kou commented Aug 24, 2022

This comment was marked as outdated.

kou commented Aug 25, 2022

This comment was marked as outdated.

kou commented Aug 26, 2022

This comment was marked as outdated.

kou commented Aug 27, 2022

This comment was marked as outdated.

ursabot commented Aug 30, 2022

ursabot commented Aug 30, 2022

jorisvandenbossche Sep 6, 2022

Choose a reason for hiding this comment

kou Sep 6, 2022

Choose a reason for hiding this comment

raulcd Sep 6, 2022

Choose a reason for hiding this comment

jorisvandenbossche Sep 6, 2022

Choose a reason for hiding this comment

jorisvandenbossche Sep 6, 2022

Choose a reason for hiding this comment

kou Sep 6, 2022

Choose a reason for hiding this comment

kou commented Aug 16, 2022 •

edited

Loading