VTK_VERSION_NUMBER is defined in vtkVersionMacros.h. All the constants are automatically extracted from the VTK header files by the wrappers, and placed directly into the module namespace, e.g.
Hence vtkConstants.py is really just a legacy file, it has only been kept so as to avoid breaking old code that uses it. Perhaps we should officially deprecate it and add a warning before the next release.
The situation with these constants is tricky, there’s nothing equivalent to modules.json to tell us what module they are defined in. We might have to generate a new file to keep track of them. But that might only be possible at build time (since it involves parsing the headers), not at configuration time.
There is a similar difficulty with e.g.
vtkmodules.vtkCommonDataModel.vtkVector3f. This class appears in vtkCommonDataModel-hierarchy.txt but is absent from modules.json.
The difficulty is that modules.json only keeps track of what headers are in what modules, it doesn’t tell us what classes and what constants are defined in the headers. The “one class per header” rule is often broken in VTK.
It might be best to use the ground truth info stored within the wrappers themselves,
modules = [ 'vtkCommonCore', 'vtkCommonDataModel', ...]
for module in modules:
module_dict = importlib.import_module('vtkmodules.' + module).__dict__
for name in module_dict:
name_to_module[name] = module
Importing the wrappers isn’t the best solution for gitlab/kwrobot checks, but it should work fine for converting the tests and examples.