arrow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Pitrou <anto...@python.org>
Subject Re: CMake refactor Heads-up
Date Mon, 18 Mar 2019 12:55:31 GMT

Ah, apparently I can do it through `-Ddouble-conversion_SOURCE=BUNDLED`.

Now there's another issue: the CMake configuration fails to find flatbuffers,
even though I have flatbuffers 1.7.1 installed from Anaconda.


CMake Error at cmake_modules/ThirdpartyToolchain.cmake:152 (find_package):
  By not providing "FindFlatbuffers.cmake" in CMAKE_MODULE_PATH this project
  has asked CMake to find a package configuration file provided by
  "Flatbuffers", but CMake did not find one.

  Could not find a package configuration file provided by "Flatbuffers" with
  any of the following names:

    FlatbuffersConfig.cmake
    flatbuffers-config.cmake

  Add the installation prefix of "Flatbuffers" to CMAKE_PREFIX_PATH or set
  "Flatbuffers_DIR" to a directory containing one of the above files.  If
  "Flatbuffers" provides a separate development package or SDK, be sure it
  has been installed.
Call Stack (most recent call first):
  cmake_modules/ThirdpartyToolchain.cmake:1485 (resolve_dependency)
  CMakeLists.txt:544 (include)



Regards

Antoine.


Le 18/03/2019 à 13:51, Antoine Pitrou a écrit :
> 
> Ok, so I have a problem.  I had the following line:
> 
>   export DOUBLE_CONVERSION_HOME=
> 
> which was used to force double-conversion to be built from source
> despite other dependencies being taken from the Conda environment.  Now
> it doesn't work anymore, and I haven't found how to emulate it.
> 
> Regards
> 
> Antoine.
> 
> 
> 
> Le 15/03/2019 à 15:38, Uwe L. Korn a écrit :
>> Hello fellow Arrow Devs,
>>
>> we have merged the CMake refactor yesterday https://github.com/apache/arrow/pull/3688
and this means that the build system behaves a bit different. The main differences are:
>>
>> * If you're in a conda environment, we automatically detect this using the environment
variable $CONDA_PREFIX and expect that all dependencies (except jemalloc and ORC) are installed
via conda.
>> * Otherwise, we will look in the standard system paths for a dependency. If it isn't
found, we use CMake's ExternalProject mechanism to build it.
>> * The *_HOME variables are not longer use and are replaced by *_ROOT variables to
use CMake's standard detection features. Be aware that dependencies are no longer written
in all caps but their preferred casing as seen in https://github.com/apache/arrow/blob/0d302125abb4b514dba210f496c574a77ce4cd1d/cpp/cmake_modules/ThirdpartyToolchain.cmake#L41-L59
>> * You can manually select the way we detect dependencies via ARROW_DEPENDENCY_SOURCE
https://github.com/apache/arrow/blob/0d302125abb4b514dba210f496c574a77ce4cd1d/cpp/CMakeLists.txt#L189-L207
The hope is that you as a developer should not normally need to change this and as packager
for distributions, you can use `ARROW_DEPENDENCY_SOURCE=SYSTEM` to ensure that ExternalProject
is not used but only packages from the package manager. If your system is in a non-default
prefix, you can indicate this by setting ARROW_PACKAGE_PREFIX.
>>
>> Also, please clear your existing CMake directories and do a fresh built to avoid
any problems. As well when you're using conda packages, please update them all using `conda
update --all` as I have errors in the packaging directly on conda-forge instead of doing workarounds
in our CMake code. A helpful information is here that conda-forge now provides a `compilers`
package that provides the whole build toolchain.
>>
>> Uwe
>>

Mime
View raw message