In the build of a native extension I am getting a laconic
LoadError: None of the selected providers can install dependency tensors.
on windows only.
The build steps for that target invoke cmake, but I see none of the standard output from the cmake build which is likely the culprit.
Is there a means to make it more verbose?
(link to build.jl: https://github.com/QuantStack/xtensor-julia/blob/master/deps/build.jl)
BuildProcess is not enabled by default on Windows. That would assume users have a compiler installed, which very few of them will on Windows. Better to build and provide binaries for Windows users.
Also note that Pkg.dir is not a correct way for a package to refer to its own location in general, if installed and loaded from elsewhere in LOAD_PATH it will not be right. Use relative paths and dirname(@__FILE__), or on 0.6 or with a minimum Compat version of 0.9.1, @__DIR__.
Thanks for your reply. Now trying with the BuildProcess enabled.
(My expectation was for build.jl to do all the build for a source distribution, but that binary packages could be distributed on other channels)
build.jl runs at install time on users’ machines. For your own maintenance
purposes you could manually enable the BuildProcess provider when you know
you have a compiler available, but maintainers don’t need Julia to run
things just for building C++ binaries.
We’re going to separate the tooling in a better way long term so
maintainers have better templates and build environments set up for
producing binaries across platforms, and the install time build script that
runs on users’ systems only has to download a platform-dependent file.
If you plan on also building a conda package via conda-forge anyway, you
could make use of their infrastructure. I haven’t been entirely sold on
using conda-forge as a general solution for Julia packages that aren’t
Python bindings for a few reasons I won’t get into right now, but if you
can make it work, go for it.
Yes, I would love to be able to use conda-forge for this sort of things, although at the moment there is no conda-forge build for julia itself. Although some binaries are available on various channels.
For the work on packaging the Cling interpreter we already had to make build variants of LLVM and Clang to include their patches. Can Julia use a stock (unpatched) LLVM version?
“maybe.” If you’re using a different LLVM version or a different set of
patches than what the source build and official binaries use, you’re mostly
on your own. It might work but it could easily FTBFS or have test failures.
Issues or PRs reporting or fixing these are welcome, but we generally stick
to a single widely-tested LLVM configuration.