I would advise against mixing these environments. Either use only packages from defaults or from conda-forge as things like boost from defaults and boost from conda-forge can be installed at the same time but then lead to segfaults.
Uwe On Mon, Mar 18, 2019, at 2:10 PM, Antoine Pitrou wrote: > > 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) > > Regards > > Antoine. > > > Le 18/03/2019 à 13:59, Uwe L. Korn a écrit : > > 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 > >>>> > >> >
