I built VTK-9.2.2 as I would like to use it dynamically within a tool if the user wants to get some graphical views.
To achieve this, a c++ library within which various “vtk” methods are exposed using “DLLEXPORT” is constructed. This library is linked with VTK.
Those methods are used afterwards within the main program using “boost::dll::import” combined with some VTK headers in order to have access to method’s definitions and decorations. Unfortunately, the headers file of some of the ones I would use, eg. vtkPoints.h, is indirectly loading vtksys/SystemTools.h (through vtkObject.h and vtkSetGet.h) within which SystemToolsManager() constructor is used while its description is contained within SystemTools.cxx.
Therefore, in order to get my main program compiling properly, I have to link it with the libvtksys library meaning that I basically failed to avoid linking my program with respect to VTK.
My question is: Is there a way to avoid this link to SystemTools during VTK compilation?
No, I think vtksys is a public dependency of VTK hence you need to link to it. However, this should be handled automatically when you use find_package(VTK … ) and target_link_library.
Do you think that this “unavoidable” dependence will be removed in upcoming VTK versions/patches? Do you think that it would be feasible to “patch” the current version of VTK in order to move the definition of the various methods used within the vtkSetGet and SystemTools header files inside those latter files in order to create a “self contained” set of headers?
Thank you very much in advance for your help.
Best regards.
@NomisTuo I think that I understand what you want to do, but please let me know if I’m wrong. You want to compile VTK as static libraries, link some (or all) of those libraries into a loadable plugin, and then expose only certain VTK classes by exporting their symbols.
The short answer is, it would be very hard to figure out which symbols to export, and it might in fact be impossible. The VTK API contains many inline functions and it does not cleanly map to a simple ABI.
The long answer is, VTK can be used in a plugin, without the main application having to link to any of VTK’s libraries or dependencies, but only if you wrap the VTK methods that you need in new functions and then export those new functions. Directly exporting the VTK methods is almost certain to fail, due to what I said in the 2nd paragraph above.
One obvious (and extensive) example of this is the VTK Python wrappers. Python itself does not link to VTK, but the VTK Python wrappers provide what is essentially a collection of shared libraries that provide an exported C API that Python can use to access VTK’s functionality. (The C API that is generated by the wrappers is Python-specific, and cannot be used for other purposes, just in case you were wondering).
If there are only a small number of VTK functionalities that you need to access through your main application, then you could manually wrap the classes and methods that you need. But it wouldn’t be a trivial undertaking, there would definitely be some design work involved.