where is Findxtl.cmake

[Ravenwater]

Trying to build xtensor on Win10 using CMake GUI.

Pulled in xtl and installed that, but I can't find where the Findxtl.cmake file is.

Building xtensor v0.17.3
CMake Error at CMakeLists.txt:31 (find_package):
By not providing "Findxtl.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "xtl", but
CMake did not find one.

It is neither in the source, nor gets build during the installation step. Looks like I am going to have the same problem with xsimd.

[wolfv]

You'll have to make install xtl or download it through conda.

The repository is here: github.com/QuantStack/xtl

[JohanMabille]

How did you install xtl?

xtl and xsimd, when installed with cmake, generate xtlTargets.cmake and xsimdTargets.cmake under ${CMAKE_INSTALL_LIBDIR}/cmake/xtl and ${CMAKE_INSTALL_LIBDIR}/cmake/xsimd, so xtensor should be able to find them.

EDIT: otherwise, as @wolfv said, you can also download it via conda it will install both sources and the cmake target files required by find_package.

[Ravenwater]

So, just that I have an answer to my question: there is no Findxtl.cmake file in the xtl repo?

My process:
clone repo
load CMakeLists.txt into CMake GUI
set CMAKE_INSTALL_PREFIX to something sensible in Win10
configure
generate
load project into Visual Studio
build all
install

installed xtl and xsimd that way, then run into "missing Findxxx.cmake" problem with xtensor. Can set xtl_DIR to the CMAKE_INSTALL_PREFIX/lib/cmake/xtl and build, but why not add the Findxxx.cmake file to the root dir of xtl and xsimd so that these are picked up automatically by dependent projects when you point their PROJECT_DIR to their repo root? Than all of this detail that is error prone would go away.

conda is wonderful on Mac and Linux, but it is not as smooth on Windows. And I want to use xtensor in C++environments, not python environments.

[SylvainCorlay]

Find[package-name].cmake files are a fallback for packages that don't provide the [project-name]Config.cmake files which is the preferred way of finding dependencies and get installed with the xtl/xtensor/xsimd packages.

The way to install xtl (or other quantstack packages) into an installation prefix is

mkdir build                                              # create a build directory
cd build                                                 # cd into it
cmake -D CMAKE_INSTALL_PREFIX=/path/to/prefix ..         # run cmake
make                                                     # build
make install                                             # install

packages will pick up their dependencies through the [package-name]Config.cmake files that got installed.

[SylvainCorlay]

Regarding conda, conda is in fact a general-purpose package manager that happens to be written in Python. It is not specific to python environments. The requirements to be packaged for conda are very much the same as to be packaged for other popular package managers such as apt-get.

Conda has the benefit of being reasonably cross platform and already having a lot of the scientific computing stack packaged for it.

[JohanMabille]

The command to install xtl with cmake on Windows is slightly different:

mkdir build
cd build
cmake -G "NMake Makefiles" -D CMAKE_INSTALL_PREFIX=/path/to/prefix ..
nmake
nmake install

This way you avoid to generate the MSVC project files and the need to open it to build and install the project. And because of the issue you are facing, I wonder if the installation files generated by cmake for MSVC is actually correct.

[Ravenwater]

Since I haven't gotten it to work yet, I don't know if the MSVC build process works or not, but I am confident that I'll get it to work.

nmake is not an option for our native Windows development as our tooling isn't cli based. Same argument for conda in our environment.

Now that I am educated that the [package-name]Config.cmake is the architecture of the tooling, I can make it work. I just had an aesthetic seizure with having to navigate the lib/cmake part of the path. We tend to build the tooling to work off the root path of the repo, so that the users only need to set that piece, as that is a piece of information they tend to know without knowing anything about the build process.

[SylvainCorlay]

I just had an aesthetic seizure with having to navigate the lib/cmake part of the path. We tend to build the tooling to work off the root path of the repo, so that the users only need to set that piece, as that is a piece of information they tend to know without knowing anything about the build process.

Yes in fact, setting the cmake install prefix is thr only thing that should be required. It should then figure out the lib/cmake thing by itself. It is a standard path.