[KDE/Mac] about the kde4_add_plugin macro, and shared vs. module building

[René J.V. Bertin]

Hello,

A while back I ran into an issue building Calligra, which uses 2 of its plugins as shared libraries to link test applications with. The kde4_add_plugin macro causes cmake to create a "shared module" if no other options are given, and on OS X that means code is compiled with `-bundle` (and possibly linked with `-bundle_loader`).

Plugins will work fine when they're built as regular shared libraries (as on Linux), so my first approach was to patch CMake so that KDE4 plugins are built that way. It took almost a year, but I did run into an issue with that approach: the aforementioned -bundle_loader flag can only be used on code compiled with -bundle (`-bundle_loader foo` tells the linker that the plugin is allowed access to foo's symbols, basically).

The easiest way out for the 2 Calligra plugins would be to use

kde4_add_plugin(foo SHARED ...)

but that means we get ${prefix}/lib/foo.dylib instead of ${prefix}/lib/kde4/foo.so, undoubtedly leading to plugin loading failure.

I've never yet had to dirty my hands trying to tweak things at this level. I know MacPorts has patches that changes the extension on certain binary object (from .dylib to .so or vice versa) but that's about all I know.

Does anyone have a suggestion what would be the best solution here? The easiest way would be not to build the 2 test cases, but I'd like something a bit more fundamental, because one day or another we'll bump into a case where a plugin is also used as a shared library for something more important than a test executable.

Or is this kind of "abuse" officially "not done"?

Thanks,
René