adang1345 / delvewheel

Self-contained Python wheels for Windows
MIT License
123 stars 12 forks source link

How to search for libraries from subprojects #55

Open WillAyd opened 2 months ago

WillAyd commented 2 months ago

I am curious if there is a best practice for bundling libraries come from subpackages of the build system. In my particular case, I am using CMake, but I believe this same issue would apply to meson as well.

To illustrate, let's assume I have a CMake dependency that I declare as:

include(FetchContent)
FetchContent_Declare(another_proj ...)
FetchContext_MakeAvailable(another_proj)

CMake will build and place the artifacts for the other project in <build_dir>/another_proj-build/, which is not something delvewheel will be able to search by default. For local builds, you may be able to influence the search path to have it find this directory, but on a tool like cibuildwheel I am under the impression that the only way to get this library into your project would be to install it into the wheel. But then when cibuildwheel tries to repair the wheel you end up with library cannot be found, requiring you to add --ignore-in-wheel and not get any of the mangling needed for the subproject library.

Is there something I am overlooking as to how this situation works? If not, is there a suggested approach on how to handle libraries from subprojects?

adang1345 commented 2 months ago

Can you use the --add-path option to specify the location of the the subproject DLLs?

WillAyd commented 2 months ago

I'll have to look at how cibuildwheel is set up. My (possibly flawed) understanding is that the generation of the sdist and repairing of the wheel happen in two different locations, possibly even in two different containers