libboost-devel CMake config: Windows DLL location bug

[headlee]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

I believe there is a discrepancy in where the Boost DLLs are installed via conda-forge vs. where the CMake config IMPORTED_LOCATION target property is set. This causes incorrect paths to DLLs when using $<TARGET_RUNTIME_DLLS:exe> CMake generator commands on Windows.

It looks like the DLLs are copied to the bin folder here. The individual Boost CMake configs have the following (using libboost_random-variant-shared.cmake as an example):

set_target_properties(Boost::random PROPERTIES
  IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE CXX
  IMPORTED_IMPLIB_RELEASE "${_BOOST_LIBDIR}/boost_random.lib"
  )

set_target_properties(Boost::random PROPERTIES
  IMPORTED_LOCATION_RELEASE "${_BOOST_LIBDIR}/boost_random.dll"
  )

IMPORTED_IMPLIB is correct and points to the proper .lib. However, IMPORTED_LOCATION uses the same _BOOST_LIBDIR, even though the DLLs are in bin.

I'm pretty new to conda-forge builds so I'm not sure the best approach to fixing this. Couple of ideas:

1. Move Boost DLLs to lib dir so CMake configs work as-is. However, this could cause issues at runtime if lib isn't on the PATH.

2. Duplicate Boost DLLs to lib. This is what I did locally to get around this issue, but it's not very graceful..

3. Patch the .cmake configs for each Boost component, making the IMPORTED_LOCATION property use something like ${_BOOST_BINDIR} (if that's even a thing)?

Installed packages

bzip2                     1.0.8                h0ad9c76_8    conda-forge
ca-certificates           2025.8.3             h4c7d964_0    conda-forge
icu                       75.1                 he0c23c2_0    conda-forge
libblas                   3.9.0           35_h5709861_mkl    conda-forge
libboost                  1.88.0               h9dfe17d_5    conda-forge
libboost-devel            1.88.0               h1c1089f_5    conda-forge
libboost-headers          1.88.0               h57928b3_5    conda-forge
libboost-python           1.88.0          py313h7084e01_5    conda-forge
libboost-python-devel     1.88.0          py313h481bd34_5    conda-forge
libcblas                  3.9.0           35_h2a3cdd5_mkl    conda-forge
libexpat                  2.7.1                hac47afa_0    conda-forge
libffi                    3.4.6                h537db12_1    conda-forge
libhwloc                  2.12.1          default_h64bd3f2_1002    conda-forge
libiconv                  1.18                 hc1393d2_2    conda-forge
liblapack                 3.9.0           35_hf9ab0e9_mkl    conda-forge
liblzma                   5.8.1                h2466b09_2    conda-forge
libmpdec                  4.0.0                h2466b09_0    conda-forge
libsqlite                 3.50.4               hf5d6505_0    conda-forge
libwinpthread             12.0.0.r4.gg4f2fc60ca      h57928b3_9    conda-forge
libxml2                   2.15.0               ha29bfb0_0    conda-forge
libxml2-16                2.15.0               h06f855e_0    conda-forge
libzlib                   1.3.1                h2466b09_2    conda-forge
llvm-openmp               20.1.8               hfa2b4ca_2    conda-forge
mkl                       2024.2.2            h57928b3_16    conda-forge
numpy                     2.3.3           py313hce7ae62_0    conda-forge
openssl                   3.5.3                h725018a_0    conda-forge
pip                       25.2               pyh145f28c_0    conda-forge
python                    3.13.7          hdf00ec1_100_cp313    conda-forge
python_abi                3.13                    8_cp313    conda-forge
tbb                       2021.13.0            h18a62a1_3    conda-forge
tk                        8.6.13               h2c6b04d_2    conda-forge
tzdata                    2025b                h78e105d_0    conda-forge
ucrt                      10.0.26100.0         h57928b3_0    conda-forge
vc                        14.3                h41ae7f8_31    conda-forge
vc14_runtime              14.44.35208         h818238b_31    conda-forge
vcomp14                   14.44.35208         h818238b_31    conda-forge
zstd                      1.5.7                hbeecb71_2    conda-forge

Environment info

conda version : 23.11.0
    conda-build version : 3.28.1
         python version : 3.8.18.final.0
                 solver : libmamba (default)
       virtual packages : __archspec=1=x86_64
                          __conda=23.11.0=0
                          __cuda=12.8=0
                          __win=0=0
       base environment : C:\Users\jon\anaconda3  (writable)
      conda av data dir : C:\Users\jon\anaconda3\etc\conda
  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/conda-forge/win-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://repo.anaconda.com/pkgs/main/win-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/win-64
                          https://repo.anaconda.com/pkgs/r/noarch
                          https://repo.anaconda.com/pkgs/msys2/win-64
                          https://repo.anaconda.com/pkgs/msys2/noarch
          package cache : C:\Users\jon\anaconda3\pkgs
                          C:\Users\jonathan.headlee\.conda\pkgs
                          C:\Users\jonathan.headlee\AppData\Local\conda\conda\pkgs
       envs directories : C:\Users\jon\anaconda3\envs
                          C:\Users\jonathan.headlee\.conda\envs
                          C:\Users\jonathan.headlee\AppData\Local\conda\conda\envs
               platform : win-64
             user-agent : conda/23.11.0 requests/2.31.0 CPython/3.8.18 Windows/10 Windows/10.0.19045 solver/libmamba conda-libmamba-solver/23.12.0 libmambapy/1.5.5
          administrator : False
             netrc file : None
           offline mode : False

[h-vetinari]

Thanks for raising this.

I'm pretty new to conda-forge builds so I'm not sure the best approach to fixing this. Couple of ideas: [...]

• Patch the .cmake configs for each Boost component, making the IMPORTED_LOCATION property use something like ${_BOOST_BINDIR} (if that's even a thing)?

Yeah, the "putting DLLs in %LIBRARY_PREFIX%\bin is a central aspect of how conda does packaging on windows, so the most reasonable solution IMO would be to patch the metadata that boost is creating. If $_BOOST_BINDIR doesn't exist, you could try ${_BOOST_LIBDIR}/../bin.