Yes… but keep that in mind. Can you try this in the parser?
static struct Foo {
public:
Foo(){}
~Foo(){}
} foo;
I also suspect of some ill-supported preprocessor language feature. VTK_MODULE_INIT unfolds into other macros, that unfolds into other macros themselves.
Yes. Like you, I don’t use CMake. Non-CMake users must include those macros explicitly. In the .cpp of my VTK widget class, I put them in the very beginning of the source file:
#include <vtkAutoInit.h>
VTK_MODULE_INIT(vtkRenderingOpenGL2) // VTK was built with vtkRenderingOpenGL2
VTK_MODULE_INIT(vtkInteractionStyle)
VTK_MODULE_INIT(vtkRenderingFreeType)
It depends on your needs (mine requires two others). But, again, getting a namespace error suggests some unsupported syntax. An incorrect module initialization would result in a blank screen like you had, a VTK error console to pop-up or even a crash.
From the documentation of vtkAutoInit.h:
This call must be made in global scope in the translation unit of your executable (which can include a shared library, but will not work as expected in a static library).
A “translation unit”, in a nutshell, is a .cpp file with all the contents of the headers, macros, autos, templates, etc. resolved into actual C++ code. That is, a source code ready to be compiled into an object file.
Despite all that, Python and Java users are able to have the VTK modules initialized in a interpreted context. So, we know it’s doable.
My first attempt would be adding the initialization of the required VTK modules to the ROOT’s parser code itself. Is it practical for you?