conan: `conan install` seemingly hangs, in fact is silently installing with no console output
Conan 1.15.0, Mac OS X 10.14.4 18E226
After terminating a conan install ..
with Ctrl-C, I ran the command again, and it appeared to hang. Wanting to collect more info, I terminated it again, and then ran conan install
with CONAN_TRACE_FILE set and discovered that it actually didn’t hang, but is silently installing a bunch of dependencies. The only output I saw while this was happening was this:
$ export CONAN_TRACE_FILE=~/conan.log && conan install -p debug ..
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=apple-clang
compiler.cppstd=17
compiler.libcxx=libc++
compiler.version=10.0
os=Macos
os_build=Macos
[options]
[build_requires]
[env]
After the install has completed, which took a good 5 minutes, I finally saw the rest of the output:
conanfile.py: Installing package
Requirements
FakeIt/2.0.5@gasuketsu/stable from 'conan-center' - Cache
boost_algorithm/1.69.0@bincrafters/stable from 'bincrafters' - Cache
boost_array/1.69.0@bincrafters/stable from 'bincrafters' - Cache
boost_assert/1.69.0@bincrafters/stable from 'bincrafters' - Cache
boost_atomic/1.69.0@bincrafters/stable from 'bincrafters' - Cache
boost_bind/1.69.0@bincrafters/stable from 'bincrafters' - Cache
boost_chrono/1.69.0@bincrafters/stable from 'bincrafters' - Cache
boost_concept_check/1.69.0@bincrafters/stable from 'bincrafters' - Cache
...
fmt/5.3.0@bincrafters/stable:2e81740c9856cbfd57822c38999d3b19830708f6 - Cache
lzma/5.2.4@bincrafters/stable:63363709da4dc3d9b6dcddd47681b79ef69bb2e7 - Missing
zlib/1.2.11@conan/stable:63363709da4dc3d9b6dcddd47681b79ef69bb2e7 - Missing
zstd/1.3.5@bincrafters/stable:63363709da4dc3d9b6dcddd47681b79ef69bb2e7 - Missing
FakeIt/2.0.5@gasuketsu/stable: Already installed!
boost_config/1.69.0@bincrafters/stable: Already installed!
boost_predef/1.69.0@bincrafters/stable: Already installed!
boost_preprocessor/1.69.0@bincrafters/stable: Already installed!
bzip2/1.0.6@conan/stable: Already installed!
doctest/2.3.1@bincrafters/stable: Already installed!
fmt/5.3.0@bincrafters/stable: Already installed!
lzma/5.2.4@bincrafters/stable: WARN: Can't find a 'lzma/5.2.4@bincrafters/stable' package for the specified settings, options and dependencies:
- Settings: arch=x86_64, build_type=Debug, compiler=apple-clang, compiler.cppstd=17, compiler.version=10.0, os=Macos
- Options: fPIC=True, shared=False
- Dependencies:
- Package ID: 63363709da4dc3d9b6dcddd47681b79ef69bb2e7
ERROR: Missing prebuilt package for 'lzma/5.2.4@bincrafters/stable'
Try to build it from sources with "--build lzma"
Or read "http://docs.conan.io/en/latest/faq/troubleshooting.html#error-missing-prebuilt-package"
Not sure what’s going on here, but thought I’d report it in case someone else runs into this.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 1
- Comments: 18 (15 by maintainers)
Please track https://github.com/conan-io/conan/issues/11604
Never for so long (you reported up to 5 minutes), but with huge graphs installing is a very time-consuming operation. After building the graph we check for available binaries given the package_id for each recipe+profile and it involves querying your remotes (if those binaries are not found in the cache). Once they are in the cache, then there is no need to query the remotes and things go really fast (that’s the reason why it appeared to you again when you change to the release build).
Using those modular boost time explode, those are ~100 libraries and we are checking for each binary package. According to your trace, each check takes more than 3 seconds (three API calls related to
conaninfo.txt
file) and those sum up your 5 minutes.The main problem here is each API call taking 1 second at least, I don’t know if it is always the same or bintray was having a problem at that time. But I’ve just tried it and I get more or less the same results.
I hope this is not an issue related to Mac or any particular OS/Terminal.
Actions to take:
OTR.- On my personal projects, I prefer to use the monolithic boost package but of course this is not a solution because the graph can be huge just because it has many libraries.