Support DLL-only plugins/modules in package_contents tests on Windows

[traversaro]

Description

package_contents.lib currently appears to assume that every DLL on Windows is accompanied by an import library (.lib).

This is correct for normal shared libraries that are intended to be linked against, but it does not work well for runtime-loaded plugins (i.e. MODULE library time on CMake).

Plugins are often intentionally built as DLL-only artifacts, without an import library. In this case, using package_contents.lib causes the package test to fail even though the expected plugin DLL is present.

For example, consider a package containing the Zenoh REST plugin (from conda-forge/zenoh-feedstock#48)

Library/bin/zenoh_plugin_rest.dll

The natural existence test would be:

tests:
  - package_contents:
      lib:
        - zenoh_plugin_rest

The DLL is correctly found:

lib: "Library/bin/zenoh_plugin_rest.dll" matched:
  - Library/bin/zenoh_plugin_rest.dll

but the test then fails because rattler-build also expects:

Library/lib/zenoh_plugin_rest.lib

resulting in an error similar to:

Package content test failed:
  No match for lib glob: Library/lib/zenoh_plugin_rest.lib

However, no .lib is expected in this case: zenoh_plugin_rest.dll is a plugin loaded dynamically at runtime and is not intended to be linked against.

Current workaround

It is possible to use package_contents.files instead:

tests:
  - package_contents:
      files:
        - if: win
          then: Library/bin/zenoh_plugin_rest.dll
        - if: linux
          then: lib/libzenoh_plugin_rest.so
        - if: osx
          then: lib/libzenoh_plugin_rest.dylib

This works, but it means losing the useful platform-independent abstraction provided by package_contents.lib.

Instead of:

tests:
  - package_contents:
      lib:
        - zenoh_plugin_rest

recipes need to duplicate the platform-specific naming and installation paths.

Proposed solution

It would be useful if package_contents could distinguish between:

1. a linkable shared library, where on Windows both the DLL and import library are expected;
2. a runtime-loaded module/plugin, where only the DLL is expected.

For example, an optional flag could be added:

tests:
  - package_contents:
      lib:
        - name: zenoh_plugin_rest
          import_library: false

Another possibility would be to introduce a dedicated plugin / module package-content test:

tests:
  - package_contents:
      plugin:
        - zenoh_plugin_rest

with platform-specific expansion roughly equivalent to:

Linux:   lib/libzenoh_plugin_rest.so
macOS:   lib/libzenoh_plugin_rest.dylib or lib/libzenoh_plugin_rest.so
Windows: Library/bin/zenoh_plugin_rest.dll

without requiring an import library on Windows.

Just not checking for .lib on Windows probably may not be a good option, as a common failure mode for Windows packaging of shared library is not exporting any symbol, that results in no .lib file being produced.

Related issue

This seems related to #2361, which discusses Windows DLL handling in package_contents.lib, particularly versioned DLL names. However, that is a different issue.