After a lot of research, things are getting gradually more with the new plugin/module concept of PV 5.7 - not only regarding “how to get things done”, but also regarding the logic behind it.
Still I am coming back to a question that was one of my first already, two or three months back: the relation between “plugins”, “modules” and finally built shared libraries. And on top of all that: the “client server wrapping”. By now I think I understood a lot, but still some corners of this field are rather fuzzy in my head, so let me just try to “explain to myself” - and the question is: please correct where I am wrong!
-
“Modules” can basically be seen as almost synonymous to a library, in my case normally shared, but could probably also be static. The content can be executable code, but also resources and whatever else you can put into a library - like Qt GUI stuff or whatever. In the CMake logic they are at the same time “targets” to which other targets can refer.
-
“Client server wrapping” of modules is required for all those parts of modules that need to be addressed through the VTK system of loading classes, but is not required if a module or library is directly linked to another part of the code, ie through the library loading / linking facilities of the operating system. There is a lot of “magic” around this “wrapping”, but this is right now not the question.
-
“Plugins” have kind of a “core” that is an XML file that contains all the interface logic, including eg C++ class names that can only be really addressed if they are “client server wrapped”. Technically, also plugins appear as shared (or maybe also static) libraries, but in that case I don’t understand yet what actually the content of this library is: is it basically only the XML file, or some info derived from it?
From the perspective of binaries generated, the step from earlier versions to version 5.7 basically means: previously a plugin was one shared library, while now it is two: one for the “plugin”, and one for the related “module”. And my “vague unserstanding” says that probably the plugin lib contains only some interface information, like what is in the XML, while the module lib contains the actual plugin code.
Actually I have now one plugin that is “xml only” - and that also does not have a second “module lib” associated. And I have a number of module libraries that are not plugins, but called by the code of many plugins, and also not “client server wrapped” as far as I see. So they are basically “plain simple shared libraries”.
This splitting into two looks like no real step ahead because it only makes things more complicated than they already were! Except if there was a way to “play with this” - like Mathieu Westphal already mentioned in a post, ie the formula “1 plugin == 2 shared libs” is only the most simple case. In my first enthusiasm I tried thus to group my plugins in a way like putting the code of a number of related plugins into one single module library, but I failed miserably - probably for some “stupid” reasons that I did not manage to solve, so I went for the “standard setup” following the above formula. I could also imagine to have entire groups of plugins in one common shared library.
I guess all this is possible, but having either examples, or even better: some generic instructions explaining the whole thing more “top down”, ie from the concept down to the realization would be a dream!
Well, at the moment these questions are more “for the future”, because now I have only the goal to get it finally “done” somehow - from the custom app with plugins to a second custom app that is build “on top of” the first to finally “superbuilds” that package these apps for deployment. I will be VERY happy if I am back to this state - where I already was until July - but with PV 5.6 only!