How to specify an variable name instead of string as --libraryPath?

[myd7349]

When using ClangSharpPInvokeGenerator, we can specify the name of the dynamic link library in the DllImport attribute using "--libraryPath" as a string.

For example:

--libraryPath=EDFlib

we will got:

[DllImport("EDFlib")]
void SomeFunc();

Sometimes, using just a string to specify the name of the dynamic link library (DLL) isn't sufficient, especially when considering cross-platform scenarios.

Scenario 1: Different Names on Different Platforms

In this scenario, the dynamic library has different names on different platforms, and we need to decide at runtime which name to use:

• Windows: The library might be named somelib.dll.
• Linux: The library might be named libsomelib.1.2.0.so, including version information.

To handle this situation, one approach is to define a variable or configuration that specifies the library name, and then allow users to customize this variable based on the platform or specific runtime conditions.

For example, in your code or configuration:

#if WINDOWS
    public const string LibraryName = "somelib.dll";
#elif LINUX
    public const string LibraryName = "libsomelib.1.2.0.so";
#endif

Then, in your DllImport attribute, use this variable:

[DllImport(LibraryName)]
public static extern void SomeFunction();

This allows flexibility to define the correct library name based on the platform or runtime conditions.

Scenario 2: Library Name Contains Dot (.)

In this scenario, the library name itself contains a dot (.), which means we must specify the full name including the file extension (dll or so) to ensure DllImport succeeds:

• Windows: The library might be named somelib.submodule.dll.
• Linux: The library might be named somelib.submodule.so.

[tannergooding]

In modern .NET the handling of different names is meant to be handled via SetDllImportResolve

This gives you the string used for LibraryName and lets you do custom resolution, including attempting to load many different versions, extensions, etc of a library. You can see that ClangSharp uses that itself here: https://source.clangsharp.dev/#ClangSharp.Interop/clang.cs, so that it can load the default libclang (which checks libclang and libclang.so/libclang.dll/libclang.dylib depending on the target OS) and can also look for common alternative names used on Unix such as libclang.so.18, libclang-18, and libclang.so.1

[myd7349]

Hi! @tannergooding Thank you! I will take a look at SetDllImportResolve.