You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@arrow.apache.org by "Uwe L. Korn (JIRA)" <ji...@apache.org> on 2019/02/18 08:02:00 UTC

[jira] [Created] (ARROW-4611) [C++] Rework CMake third-party logic

Uwe L. Korn created ARROW-4611:
----------------------------------

             Summary: [C++] Rework CMake third-party logic
                 Key: ARROW-4611
                 URL: https://issues.apache.org/jira/browse/ARROW-4611
             Project: Apache Arrow
          Issue Type: Improvement
          Components: C++, Packaging
            Reporter: Uwe L. Korn
            Assignee: Uwe L. Korn
             Fix For: 0.13.0


Instead of the current approach we are taking with the {{*_HOME}} variables, we should use more CMake features and also give users of Arrow a more high-level control. This is going to be a rather lengthy issue with a lot of subtasks.
 * Let the user decide on the top-level how dependencies should be handled. At the moment I can think of the following modes:
 ** AUTO: Guess the packaging system we're running in, use this where possible, otherwise build the dependencies through the {{ExternalProject}} logic.
 ** BUNDLED: Don't use any dependencies, build them all through {{ExternalProject}}
 ** SYSTEM: Use CMake's {{find_package}} and {{find_library}} without any custom paths. If packages are on non-default locations, let the user indicate it from the outside using the {{*_ROOT}} variables.
 ** CONDA: Same as SYSTEM but set all {{*_ROOT}} variables to {{ENV\{CONDA_PREFIX\}}}.
 ** BREW: This uses SYSTEM but asks {{brew}} for some dependencies for their installation prefix.
 * prefer dynamic linkage where possible
 * Use {{pkg-config}} and {{*Targets.cmake}} files in projects that publish these
 * Ensure that the necessary integration tests are in place (Fedora, Debian, Ubuntu, Alpine)
 * Integration tests that Arrow's {{*Targets.cmake}} and {{arrow.pc}} work.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)