[bug] Bazeldeps: build file is not correct for shared libary on Windows platform

Environment Details (include every applicable attribute)

• Operating System+version: Windows 10
• Compiler+version:
• Conan version: 1.48.1
• Python version: 3.10.1

Steps to reproduce (Include if Applicable)

For shared libraries on Windows platform, the correct way to import them is using interface_library and shared_library together, like this:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # mylib.lib is a import library for mylib.dll which will be passed to linker
  interface_library = "mylib.lib",
  # mylib.dll will be available for runtime
  shared_library = "mylib.dll",
)

Here is the doc.

Currently, bazel generator will generate BUILD file with shared libraries on Windows in this way:

cc_import(
    name = "XXXprecompiled",
    shared_library = "lib/XXX.lib"
)

According to the conan doc, DLL files are put in the bin directory. So we need to get corresponding DLL paths from bin directory.

Another problem we have is that DLL file of a library may depends on another DLL file. The publisher may put them all in the bin dir. But those DLL file won’t be mention in the libs so bazel generator will skip those DLL libs.

We tried a super hacky way to solve this problem: We iterator the bin dir, if DLL file is encountered we list it as a shared library. If the corresponding interface lib is in libs, we will generate cc_import with both interface_library and shared_library. If only DLL file is present, we generate cc_import with shared_library only. Like this:

cc_import(
    name = "XXXprecompiled",
    interface_library = "lib/XXX.lib",
    shared_library = "bin/XXX.dll"
)


cc_import(
    name = "YYYprecompiled",
    shared_library = "bin/YYY.dll"
)

This also solves another problem where the publisher may forget to the shared attribute to True. Bazel generator will assume the lib is static.

This solution actually works well internally in our project. But I feel it’s too hacky for a general solution. If anyone is interested in our solution, I can create a branch and link it here.

[memsharded]

PR merged, it will be in 1.49. Thanks!

[kkpattern]

Not sure what you mean,

I was talking about the hacky code I didn’t commit. In my first commit in our internal conan repo, I was doing it differently. In that commit, I deliberately ignored the libs option, but iterate the bin directory directly. If a DLL file is found, I will check whether there is a corresponding lib. If so, I will use the shared_library plus interface_library. If not, I will use shared_library directly.

The reason I do this is because in our corp, some libs are uploaded “incorrectly”. For example, some libraries will completely forget to set the libs option, so we need to deal with these libraries. But for official releases, I think it’s up to the user who publish the library to make sure they have the libs and shared options set correctly. So I did not submit the corresponding hacky code in the pull request.

So I think we can merge the pull request. If we do want to handle the cases I mentioned above I can create another PR.