nathanwbrei
commented
4 weeks ago I'm thinking that maybe the JANA version string (and possibly the splash screen, too) should be printed from JApplication::Init() or JApplication::Run(), not from the CLI. There are two reasons for this: Firstly, we want the version number to be accessible even when JANA is embedded inside something much larger and more complex, e.g. TRIDAS. Secondly, the version string is fundamentally the JANA developer's responsibility, not it's downstream users'. Of course, JVersion.h needs to stay accessible to users just in case we accidentally make breaking changes that they will have to constexpr if their way around.
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.
Yet another related issue is all of the preprocessor defines (like JANA2_HAVE_PODIO) which enter our code via different mechanisms. Compiling plugins with conflicting defines can also introduce really weird and difficult-to-debug problems. In a sense, this is also version information. I could imagine us putting all of our JVersion.h and jana-config.h and CMake defines into a single JConfig.h file whose format exactly matches the spack spec. The plugin loader could then easily warn when this spec is being violated.
As per: https://github.com/eic/EICrecon/pull/865#discussion_r1411189153