-
Notifications
You must be signed in to change notification settings - Fork 4.3k
In #6285 it appears that we added .pc files for things like arrow-csv, arrow-json, etc... My best guess is that this was done to signal for a given Arrow installation, if it was built with support for those options. However, it doesn't appear that there is a CMake equivalent (?) so its hard to rely on that mechanism universally.
Taking Meson as an example, its trivial to see if the host system provides arrow-compute, whether through pkgconfig or through CMake's own discovery:
arrow_compute_dep = dependency( 'arrow-compute', 'ArrowCompute', modules: ['ArrowCompute::arrow_compute_shared'], )
but for something like arrow-csv there is no equivalent CMake discovery (?)
arrow_csv_dep = dependency( 'arrow-csv', # works fine if arrow-csv.pc exists 'ArrowCsv', # not a real thing - info unavailable for CMake installation )
All reactions
-
👀 1
Replies: 2 comments 3 replies
All reactions
I didn't imagine Meson use case when I created it...
In CMake, we can use the following to check CSV availability:
find_package(Arrow REQUIRED) if(NOT ARROW_CSV) message(FATAL_ERROR "CSV must be enabled") endif()
See also how Apache Arrow C GLib does:
Lines 101 to 142 in 5a48044
If we want to provide the same interface for pkg-config and CMake package, I suggest that we add variables to arrow.pc something like the following:
diff --git a/cpp/src/arrow/arrow.pc.in b/cpp/src/arrow/arrow.pc.in index 309789379a..27d2899ccd 100644 --- a/cpp/src/arrow/arrow.pc.in +++ b/cpp/src/arrow/arrow.pc.in @@ -23,6 +23,8 @@ so_version=@ARROW_SO_VERSION@ abi_version=@ARROW_SO_VERSION@ full_so_version=@ARROW_FULL_SO_VERSION@ +csv=@ARROW_CSV@ + Name: Apache Arrow Description: Arrow is a set of technologies that enable big-data systems to process and move data fast. Version: @ARROW_VERSION@
With the approach, we can use the following Meson configuration:
assert( arrow.get_variable(cmake: 'ARROW_CSV', pkgconfig: 'csv', default_value: 'OFF') == 'ON', 'CSV module must be enabled', )
In pkg-config context, pkgconf --exists arrow-csv is easier use than [ "$(pkgconf --variable csv arrow)" = "ON" ]. So we should not remove arrow-csv with the approach. The approach is just for CMake package compatibility.
All reactions
If we want to provide the same interface for pkg-config and CMake package, I suggest that we add variables to
arrow.pcsomething like the following:
Seems reasonable. Would there be any merit to an alternative of adding FindArrowCSV.cmake, FindArrowJSON.cmake, etc...? Without having to think about Arrow packaging "internals," my thinking is that its consistent to just say "if you can find the package, its enabled" regardless of if you use pkg-conf or cmake
All reactions
We can't provide meaningful CMake target for ArrowCSV and so on because they don't need additional libraries nor build flags.
We can provide ArrowCSVConfig.cmake and define the following useless CMake target in ArrowCSVConfig.cmake:
find_dependency(Arrow) if(ARROW_BUILD_SHARED) add_library(Arrow::arrow_csv_shared INTERFACE IMPORTED) target_link_libraries(Arrow::arrow_csv_shared INTERFACE Arrow::arrow_shared) endif() if(ARROW_BUILD_STATIC) add_library(Arrow::arrow_csv_static INTERFACE IMPORTED) target_link_libraries(Arrow::arrow_csv_static INTERFACE Arrow::arrow_static) endif()
I don't have a strong opinion which approach is better. We can provide one of them or both of them.
All reactions
I don't know, but at some point we might want to have a dedicated libarrow_csv.so.