Orc unable to find dependencies, even when they exist

[WillAyd]

To reproduce the issue you can create a conda environment with orc and a third party dependency, like Snappy:

$ conda create -n foo orc snappy
$ conda activate foo

With the minimal CMake project below, no errors occur during setup:

cmake_minimum_required(VERSION 3.2)
project(foo)

find_package(Snappy REQUIRED)

However, if you add a call to find orc, you will then get an error that Snappy could not be found:

cmake_minimum_required(VERSION 3.2)
project(foo)

find_package(Snappy REQUIRED)
find_package(orc REQUIRED)

$ cmake -S . -B build
-- SNAPPY_HOME: 
CMake Error at /home/will/miniforge3/envs/foo/lib/cmake/orc/FindSnappy.cmake:80 (message):
  Could not find Snappy in system search paths.
Call Stack (most recent call first):
  /usr/share/cmake-3.31/Modules/CMakeFindDependencyMacro.cmake:76 (find_package)
  /home/will/miniforge3/envs/foo/lib/cmake/orc/orcConfig.cmake:72 (find_dependency)
  CMakeLists.txt:5 (find_package)

This issue was first discovered downstream in Apache Arrow (see apache/arrow#46906 (comment)) and appears to have started with Orc 2.1.0

[WillAyd]

This may be the same or similar to @h-vetinari issue in #2147

FWIW, the orc distribution provides custom CMake Find* files at ${CONDA_PREFIX}/lib/cmake/orc/:

$ ls ${CONDA_PREFIX}/lib/cmake/orc/Find*
/home/will/miniforge3/envs/foo/lib/cmake/orc/FindLZ4.cmake
/home/will/miniforge3/envs/foo/lib/cmake/orc/FindProtobuf.cmake
/home/will/miniforge3/envs/foo/lib/cmake/orc/FindSnappy.cmake
/home/will/miniforge3/envs/foo/lib/cmake/orc/FindZLIB.cmake
/home/will/miniforge3/envs/foo/lib/cmake/orc/FindZSTD.cmake

If you remove or rename FindSnappy.cmake, then it appears that CMake can correctly resolve the location for it

[wgtmac]

Is it simpler to introduce a ORC_PACKAGE_KIND=conda mode like conan and vcpkg so Apache ORC does not install custom findXXX modules at all?

cc @h-vetinari

[h-vetinari]

Yes, this would be preferable IMO, see #2147. That issue is talking about build-time, but obviously installing these custom Find* scripts is not necessary (or sometimes even unhelpful) in an ecosystem with complete CMake metadata for these libraries.

[WillAyd]

It seems like the suggestion from Apache Arrow is for orc to use the CONFIG mode search of find_package - is that also not an option?

apache/arrow#46906 (comment)

I don't fully grok all of CMake's requirements for dependency resolution so I may be overlooking something, but it seems like requiring a user to set ORC_PACKAGE_KIND=conda to work around issues with the built-in dependency resolution is making things more complicated than they need to be (?)

[wgtmac]

Yes, using CONFIG mode is considered as well. I agree that ORC_PACKAGE_KIND makes things more complicated. I was also thinking of totally removing the legacy FindXXX.cmake modules to make the dependency management easier. Unfortunately I am busy these days. I'll explore this at the beginning of October.

[dongjoon-hyun]

Thank you all.

According to the above discussion, ORC-1622 could be the root cause of this ?

appears to have started with Orc 2.1.0

• ORC-1622: [C++] Support conan packaging #1815

[WillAyd]

If I had to guess it would start back in https://issues.apache.org/jira/browse/ORC-1689, although I'm not sure of an easy way to test that