# \[BinDeps\] Is it possible to have a more verbose output about the build

**URL:** <https://discourse.julialang.org/t/bindeps-is-it-possible-to-have-a-more-verbose-output-about-the-build/3423>\
**Category:** General Usage\
**Created:** [April 28, 2017, 8:43pm UTC](https://discourse.julialang.org/t/bindeps-is-it-possible-to-have-a-more-verbose-output-about-the-build/3423 "2017-04-28T20:43:03Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![SylvainCorlay](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sylvaincorlay/32/923_2.png) [@SylvainCorlay](https://discourse.julialang.org/u/SylvainCorlay)\
**Post date:** [April 28, 2017, 8:43pm UTC](https://discourse.julialang.org/t/bindeps-is-it-possible-to-have-a-more-verbose-output-about-the-build/3423/1 "2017-04-28T20:43:03Z")

</div>

In the build of a native extension I am getting a laconic

```julia
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](https://github.com/QuantStack/xtensor-julia/blob/master/deps/build.jl))

---

<div class="post-metadata">

**Author:** ![tkelman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkelman/32/692_2.png) [@tkelman](https://discourse.julialang.org/u/tkelman)\
**Post date:** [April 28, 2017, 9:16pm UTC](https://discourse.julialang.org/t/bindeps-is-it-possible-to-have-a-more-verbose-output-about-the-build/3423/2 "2017-04-28T21:16:22Z")

</div>

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__ `.

---

<div class="post-metadata">

**Author:** ![SylvainCorlay](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sylvaincorlay/32/923_2.png) [@SylvainCorlay](https://discourse.julialang.org/u/SylvainCorlay)\
**Post date:** [April 28, 2017, 9:40pm UTC](https://discourse.julialang.org/t/bindeps-is-it-possible-to-have-a-more-verbose-output-about-the-build/3423/3 "2017-04-28T21:40:43Z")

</div>

Thanks for your reply. Now trying with the [BuildProcess enabled](https://github.com/QuantStack/xtensor-julia/pull/30/commits/5f40b4977aa1c8ce4566b2bb3a8e2a9f00666077).

(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)

---

<div class="post-metadata">

**Author:** ![tkelman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkelman/32/692_2.png) [@tkelman](https://discourse.julialang.org/u/tkelman)\
**Post date:** [April 28, 2017, 9:51pm UTC](https://discourse.julialang.org/t/bindeps-is-it-possible-to-have-a-more-verbose-output-about-the-build/3423/4 "2017-04-28T21:51:55Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![SylvainCorlay](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sylvaincorlay/32/923_2.png) [@SylvainCorlay](https://discourse.julialang.org/u/SylvainCorlay)\
**Post date:** [April 28, 2017, 10:02pm UTC](https://discourse.julialang.org/t/bindeps-is-it-possible-to-have-a-more-verbose-output-about-the-build/3423/5 "2017-04-28T22:02:12Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![tkelman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkelman/32/692_2.png) [@tkelman](https://discourse.julialang.org/u/tkelman)\
**Post date:** [April 28, 2017, 10:08pm UTC](https://discourse.julialang.org/t/bindeps-is-it-possible-to-have-a-more-verbose-output-about-the-build/3423/6 "2017-04-28T22:08:05Z")

</div>

“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.