This is a common source of errors, usually because JANA_HOME is incorrectly set. There's two general approaches we could take:
Add a uint64_t GetJANAVersion() callback to the ad-hoc plugin interface. The plugin loader could do nothing (or warn) if the user hasn't provided this callback.
Introduce a new JPlugin interface. This is something I've wanted to do anyway. It would let us add functionality to plugins with much less user intervention/coordination.
Previous discussion:
Relatedly, I'd like the plugin manager to print a loud warning if a plugin was compiled with a different version number compared to the program itself. I'm not sure yet if we can do this with the current InitPlugin idiom. Part of me wants to move away from the InitPlugin idiom anyhow and introduce an actual Plugin object. (This is what I did for PHASM.) Right now there is a lot of bookkeeping to track the plugin name for each component (mainly for error handling), and this is done in a hacky way because plugins don't have explicit representation in our object model.
This is a common source of errors, usually because JANA_HOME is incorrectly set. There's two general approaches we could take:
uint64_t GetJANAVersion()callback to the ad-hoc plugin interface. The plugin loader could do nothing (or warn) if the user hasn't provided this callback.JPlugininterface. This is something I've wanted to do anyway. It would let us add functionality to plugins with much less user intervention/coordination.Previous discussion: