[
https://issues.apache.org/jira/browse/ORC-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gang Wu updated ORC-2235:
-------------------------
Description:
h2. Problem
The installed C++ {{orcConfig.cmake}} saves {{CMAKE_MODULE_PATH}}, replaces it
with ORC's CMake package directory, discovers its system dependencies with
{{find_dependency()}}, and then restores the original path.
When a dependency cannot be found, {{find_dependency()}} sets {{orc_FOUND}} to
false and calls {{return()}}. This exits the config file before the restoration
code runs, leaking ORC's module path into the consuming project.
This was observed downstream in Apache Arrow: ORC's {{LZ4Alt}} dependency
discovery failed, Arrow fell back to another ORC discovery path, and a later
AWS dependency lookup failed because Arrow's {{FindAWSSDKAlt.cmake}} was no
longer on {{CMAKE_MODULE_PATH}}. The AWS error was a secondary symptom, not
necessarily a missing AWS SDK.
h2. Reproduction
With an installed ORC package whose system dependency cannot be found:
{code:cmake}
set(CMAKE_MODULE_PATH "/consumer/cmake_modules")
find_package(orc CONFIG QUIET)
# orc_FOUND is false, but CMAKE_MODULE_PATH now points to ORC's package
directory.
{code}
The problem is also reproducible from the current main-branch config template
(32046606774da481182dce2956f336dc8e79a579) with a mock missing dependency.
h2. Proposed fix
Isolate dependency discovery in a CMake variable scope using {{block(SCOPE_FOR
VARIABLES PROPAGATE orc_FOUND orc_NOT_FOUND_MESSAGE)}}. This restores the
caller's variables even when {{find_dependency()}} returns early, while
preserving the package failure state and imported dependency targets.
Validate the fix using temporary, out-of-tree configure checks for successful
and unsuccessful dependency discovery, with {{CMAKE_MODULE_PATH}} initially
undefined, empty, or containing multiple directories. Keep the source patch
limited to {{orcConfig.cmake.in}}, without adding test files or modifying test
CMakeLists files.
The separate issue of selecting LZ4 from Homebrew versus Conda is outside the
scope of this fix.
h2. References
* Arrow workaround: https://github.com/apache/arrow/pull/55415
* Downstream report: https://github.com/apache/arrow/issues/55357
was:
h2. Problem
The installed C++ {{orcConfig.cmake}} saves {{CMAKE_MODULE_PATH}}, replaces it
with ORC's CMake package directory, discovers its system dependencies with
{{find_dependency()}}, and then restores the original path.
When a dependency cannot be found, {{find_dependency()}} sets {{orc_FOUND}} to
false and calls {{return()}}. This exits the config file before the restoration
code runs, leaking ORC's module path into the consuming project.
This was observed downstream in Apache Arrow: ORC's {{LZ4Alt}} dependency
discovery failed, Arrow fell back to another ORC discovery path, and a later
AWS dependency lookup failed because Arrow's {{FindAWSSDKAlt.cmake}} was no
longer on {{CMAKE_MODULE_PATH}}. The AWS error was a secondary symptom, not
necessarily a missing AWS SDK.
h2. Reproduction
With an installed ORC package whose system dependency cannot be found:
{code:cmake}
set(CMAKE_MODULE_PATH "/consumer/cmake_modules")
find_package(orc CONFIG QUIET)
# orc_FOUND is false, but CMAKE_MODULE_PATH now points to ORC's package
directory.
{code}
The problem is also reproducible from the current main-branch config template
(32046606774da481182dce2956f336dc8e79a579) with a mock missing dependency.
h2. Proposed fix
Isolate dependency discovery in a CMake variable scope using {{block(SCOPE_FOR
VARIABLES PROPAGATE orc_FOUND orc_NOT_FOUND_MESSAGE)}}. This restores the
caller's variables even when {{find_dependency()}} returns early, while
preserving the package failure state and imported dependency targets.
Add configure-only regression tests for successful and unsuccessful dependency
discovery, with {{CMAKE_MODULE_PATH}} initially undefined, empty, or containing
multiple directories.
The separate issue of selecting LZ4 from Homebrew versus Conda is outside the
scope of this fix.
h2. References
* Arrow workaround: https://github.com/apache/arrow/pull/55415
* Downstream report: https://github.com/apache/arrow/issues/55357
> [C++] Preserve CMAKE_MODULE_PATH when dependency discovery fails
> ----------------------------------------------------------------
>
> Key: ORC-2235
> URL: https://issues.apache.org/jira/browse/ORC-2235
> Project: ORC
> Issue Type: Bug
> Components: build, C++
> Affects Versions: 3.0.0, 2.3.1
> Reporter: Gang Wu
> Assignee: Gang Wu
> Priority: Major
> Fix For: 3.0.0
>
>
> h2. Problem
> The installed C++ {{orcConfig.cmake}} saves {{CMAKE_MODULE_PATH}}, replaces
> it with ORC's CMake package directory, discovers its system dependencies with
> {{find_dependency()}}, and then restores the original path.
> When a dependency cannot be found, {{find_dependency()}} sets {{orc_FOUND}}
> to false and calls {{return()}}. This exits the config file before the
> restoration code runs, leaking ORC's module path into the consuming project.
> This was observed downstream in Apache Arrow: ORC's {{LZ4Alt}} dependency
> discovery failed, Arrow fell back to another ORC discovery path, and a later
> AWS dependency lookup failed because Arrow's {{FindAWSSDKAlt.cmake}} was no
> longer on {{CMAKE_MODULE_PATH}}. The AWS error was a secondary symptom, not
> necessarily a missing AWS SDK.
> h2. Reproduction
> With an installed ORC package whose system dependency cannot be found:
> {code:cmake}
> set(CMAKE_MODULE_PATH "/consumer/cmake_modules")
> find_package(orc CONFIG QUIET)
> # orc_FOUND is false, but CMAKE_MODULE_PATH now points to ORC's package
> directory.
> {code}
> The problem is also reproducible from the current main-branch config template
> (32046606774da481182dce2956f336dc8e79a579) with a mock missing dependency.
> h2. Proposed fix
> Isolate dependency discovery in a CMake variable scope using
> {{block(SCOPE_FOR VARIABLES PROPAGATE orc_FOUND orc_NOT_FOUND_MESSAGE)}}.
> This restores the caller's variables even when {{find_dependency()}} returns
> early, while preserving the package failure state and imported dependency
> targets.
> Validate the fix using temporary, out-of-tree configure checks for successful
> and unsuccessful dependency discovery, with {{CMAKE_MODULE_PATH}} initially
> undefined, empty, or containing multiple directories. Keep the source patch
> limited to {{orcConfig.cmake.in}}, without adding test files or modifying
> test CMakeLists files.
> The separate issue of selecting LZ4 from Homebrew versus Conda is outside the
> scope of this fix.
> h2. References
> * Arrow workaround: https://github.com/apache/arrow/pull/55415
> * Downstream report: https://github.com/apache/arrow/issues/55357
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
