Magnum::PluginManager::Manager Prints warnings for missing conf files - ability to turn this off?

[TrevorCash]

Hi Mosra,

I am using the plugin manager to load plugins - I set the plugin load directory to the bin dir of my application.

I am getting alot of printouts to the console for what seems to be all the dlls in the bin directory when the plugin manager is doing its search. Is there a way to turn off these runtime printed warnings?

...
PluginManager::Manager: ....\bin\x86_64\Debug\/MagnumSceneGraph-d.conf was not found
PluginManager::Manager: ....\bin\x86_64\Debug\/MagnumSceneTools-d.conf was not found
PluginManager::Manager: ....\bin\x86_64\Debug\/MagnumShaderTools-d.conf was not found
PluginManager::Manager: ....\bin\x86_64\Debug\/MagnumShaders-d.conf was not found
PluginManager::Manager: ....\bin\x86_64\Debug\/MagnumText-d.conf was not found
PluginManager::Manager: ....\bin\x86_64\Debug\/MagnumTextureTools-d.conf was not found
PluginManager::Manager: ....\bin\x86_64\Debug\/MagnumTrade-d.conf was not found
PluginManager::Manager: ....\bin\x86_64\Debug\/ShaferFilechck.LTCNT.conf was not found
PluginManager::Manager: ....\bin\x86_64\Debug\/ShaferFilechck.conf was not found
PluginManager::Manager: ....\bin\x86_64\Debug\/TLUP_64.conf was not found
PluginManager::Manager: ....\bin\x86_64\Debug\/TL_LDC.1.1.0.conf was not found
PluginManager::Manager: ....\bin\x86_64\Debug\/TL_LDC.2.0.0.conf was not found
PluginManager::Manager: ....\bin\x86_64\Debug\/TL_LDC.conf was not found
PluginManager::Manager: ....\bin\x86_64\Debug\/api-ms-win-core-console-l1-1-0.conf was not found
PluginManager::Manager: ....\bin\x86_64\Debug\/api-ms-win-core-console-l1-2-0.conf was not found
...

[mosra]

I set the plugin load directory to the bin dir of my application.

I don't recommend doing this. To make plugin dependencies work (such as a glTF importer plugin optionally needing to load PNG, JPEG, ... importer plugins), the plugin manager performs plugin discovery in that directory.

If you put plugins as well as any other DLLs all together, the plugin assumes all of those are loadable plugins, which can have nasty consequences, such as the manager attempting to load an arbitrary DLL and then crashing because that DLL didn't expect to be loaded that way. That it now complains about *.conf files is just a consequence of this not being a good approach in the first place.

Even if you wouldn't have the other DLLs there and would have just the actual plugins put all together, it's still a problem, because the manager then assumes all of those are plugins of the same interface, while some could be image importers, some image converters and such. With that, loading a plugin that depends on other plugins will no longer work correctly.

What's your use case, exactly? What prevents you from preserving the original filesystem structure, i.e. plugins being in bin/magnum/importers, bin/magnum/imageconverters etc.? Note that e.g. Qt does the same and is even pickier about it, it requires you to have them put into a certain directory without an ability to override this at all.

[TrevorCash]

Hi @mosra ,

The particular project I am working with has alot of outside packaging routines and things. Putting the plugins in subdirectories might be doable - right now Its alot of changes to a working build and installer system. For now I am going to silence console output temporarily.

[mosra]

Some other options you could do instead:

1. Build the plugins as static and link them statically, and then point the plugin manager to, say, "nonexistent". That directory doesn't exist, which causes it to be silent and not perform any lookup.

2. Or keep the plugins dynamic, point the plugin manager to "nonexistent" and then load the plugins via their full filename. Either directly once you use them (which might be annoying), or load the ones you need upfront. Once loaded, they can be referenced with their short name. Something like this for example:

PluginManager::Manager<Trade::AbstractImporter> manager{"nonexistent"};
manager.load(Utility::Path::join(*Utility::Path::executableLocation(), "AnyImageImporter.dll"));
manager.load(Utility::Path::join(*Utility::Path::executableLocation(), "AnySceneImporter.dll"));
manager.load(Utility::Path::join(*Utility::Path::executableLocation(), "StbImageImporter.dll"));
manager.load(Utility::Path::join(*Utility::Path::executableLocation(), "GltfImporter.dll"));
...

// The short name works once loaded
Containers::Pointer<Trade::AbstractImporter> importer = manager.loadAndInstantiate("AnySceneImporter");

[TrevorCash]

Thanks @mosra , I switched to using the above.

[TrevorCash]

Edit: The Above works on linux for me - But I still get errors when trying this approach on macos and windows. It could be a pathing format issue.

[mosra]

What kind of errors you get? Or you mean you still get the "conf was not found" warnings there?

Besides the obvious difference with extension being *.so on linux + mac and *.dll on windows, I don't see why it wouldn't work.