Hello Antoine, you're running into https://github.com/ContinuumIO/anaconda-issues/issues/10731 I would rather have Anaconda fix this but we can also add alternative detection for this. I've opened https://issues.apache.org/jira/browse/ARROW-4946, 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: > > > > 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 > >> >
