arrow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Pitrou <>
Subject Re: CMake refactor Heads-up
Date Mon, 18 Mar 2019 13:10:18 GMT

Well, in the meantime I can just use the conda-forge packages.
(though there are regular issues when updating packages where conda
switches back and forth from Anaconda and conda-forge packages)



Le 18/03/2019 à 13:59, Uwe L. Korn a écrit :
> Hello Antoine,
> you're running into I would
rather have Anaconda fix this but we can also add alternative detection for this. I've opened,  I can then look into this the next hours/tomorrow.
As with double-conversion, `-DFlatbuffers_SOURCE=BUNDLED` is a possible workaround until then.
> Uwe
> On Mon, Mar 18, 2019, at 1:55 PM, Antoine Pitrou wrote:
>> 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:
>>> 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
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
>>>> * You can manually select the way we detect dependencies via ARROW_DEPENDENCY_SOURCE
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

View raw message