The way I’ve had this working (and works in all samples except the multiproject one) is to avoid using ‘dllimport’ entirely. But I can get away with that because my code is dead simple.
The way I see it, the header file belongs to the library. And in this case, there is effectively a different header file for the static or shared linkages of the library. I would prefer a solution that made it easy for libraries to be packaged in this way: so that when linking to the static variant the executable would automatically get the ‘declspec-free’ version of the library. This should work for project dependencies like we have now, as well as for downloaded and resolved dependencies.
Or perhaps the library itself contributes to the compiler defines of the consuming executable. So the metadata for a shared library would say “here are my headers, you must compile with /Dmylib_dll_import”, and Gradle would automatically define that macro.
For now, you don’t need to write your library code so that it can be consumed as both a static and shared library. If it’s always a shared library, and you only consume it as such, then your code can be simpler. If you want the ability to produce both, you need to do some extra work, and there is going to be some knowledge in the consumer of how to set the correct compiler args for the headers.
(a) The library configuration itself could dictate linkage.
At some stage we’ll make it possible to declare that a library is always static, always shared, or both. Then you won’t need to declare a linkage in the consumer when there is only one option.