Recently when developing smtk plugins, I spent hours to debug a mysterious bug and it turns out that it’s just because my custom plugin is linking against smtk 3.3.0, but my CMB is linking again 3.2.0. Thus the new feature is never triggered.
Suggestions
If the custom plugins are linking against version A while model builder is linking against smtk version B, it should error out. We could make the version to be a static string/ int for comparison purpose.
For smtk plugins, plugins with different linkages should are detected and warned.
When designing the versioning in smtk, we have left many rooms and spaces for utilization and improvement. Now it’s a good time to explore them. Thoughts and Ideas?
We currently have a class smtk::common::Version automatically generated from CMake variables (you can find it in your build directory). We could use this class at compile time to imprint versions (we may have to make them constexpr, as this was written pre-c++11) in our plugins and compare against the runtime-evaluated versions in a plugin’s registration code. What do you think?
That would be good for modelbuilder (which could use the SMTK version it is provided) but would not do anything for ParaView. Should we also try to detect when different plugins use different versions of SMTK? That might potentially catch even more problems.
LGTM. My understanding is that we require all plugins to be built with the same version of smtk so the registration code only needs to check if the version matches.
In order to imprint versions for each plugin, does the plugins now have its own version class or just a constexpr string/int?
I think the idea is that PluginClient or PluginClientBase would include version numbers. When the PluginManager registers a plugin, it could warn or error if the version numbers in the client do not match what it has already registered (if any).
If you want to get fancy, you can make the PluginManager do different things depending on differences in the major/minor/patch version numbers. For instance, a PluginClient might indicate that it does not care about minor version mismatches. I would not attempt this in the first pass.
Does this mean we’re updating the version number on every incompatible change? Every feature addition?
With shared libraries, you’ve lost if there are incompatibilities as soon as you dlopen the library. It could have brought in some incompatible SMTK and there’s no reliable way to evict it (static initializers being what they are).
One possible canary solution would be to embed the version information into the symbol that is generated and looked for by the plugin loading mechanism. For example, instead of some_static_function lookup, you lookup some_static_prefix_${versioninfo}.