Open gregdenay opened 1 year ago
@beckermr
When you have time, can you please confirm if this is true?
Is libboost-devel missing static libraries after the unification?
My conda build in windows is failing, because the consumer is trying to force static libraries
set(Boost_USE_STATIC_LIBS ON)
I think I remember hearing that static libraries are frowned upon in conda-forge ethos.
We have not been shipping static libraries since almost 4 years (https://github.com/conda-forge/boost-cpp-feedstock/commit/dc9517a23d2eb782f5006ee177c77247a0a9b041), so this is unrelated to the unification.
It's true that conda-forge generally tries to avoid static libraries, but exceptions do exist (where there is a strong case to be made for their necessity), and we have a few packages where we provide both shared & static libraries (in separate outputs). Boost could become one of them, i.e. with a libboost-static
depending on libboost-devel
c.f. also https://github.com/conda-forge/boost-cpp-feedstock/pull/151.
Feel free to make that case and/or try your hand at a PR!
PS. It's very likely worth a shot to patch out set(Boost_USE_STATIC_LIBS ON)
in the consuming project - this should work fine.
We have not been shipping static libraries since almost 4 years (conda-forge/boost-cpp-feedstock@dc9517a), so this is unrelated to the unification.
It's true that conda-forge generally tries to avoid static libraries, but exceptions do exist (where there is a strong case to be made for their necessity), and we have a few packages where we provide both shared & static libraries (in separate outputs). Boost could become one of them, i.e. with a
libboost-static
depending onlibboost-devel
c.f. also conda-forge/boost-cpp-feedstock#151.Feel free to make that case and/or try your hand at a PR!
PS. It's very likely worth a shot to patch out
set(Boost_USE_STATIC_LIBS ON)
in the consuming project - this should work fine.
Thank you very much @h-vetinari for your feedback.
I got it patched soon after posting this. :-).
I'll need to reach out to the project owners to ask why they want to force static boost. I have a feeling the answer is that they want to minimize the number of dependencies and libraries that their customers see, and they don't have conda as part of their production flow / customer usage.
In my view, there is no reason for them to hardcode it this way, they can use a cmake option with a default of static for their production flow, but allow conda users to do -DBoost_USE_STATIC_LIBS=OFF
Comment:
I am trying to update a bioconda recipe for a package requiring the BOOST static libraries to build (SKESA). However, it seems that the static libraries are missing from the /lib folder of the conda environment.
On debian 10:
~/anaconda3/envs/boost/include/boost/ exists ~/anaconda3/envs/boost/lib contains the libboost_xxx.so files but no libboost_xxx.a file.
Looking at the recipe here it seems like the static libraries should be installed. I am a bit confused with the otrher stock (boost-cpp) for which the static libraries are not installed. The mamba log lists both packages:
What am I missing?