All the examples I see that use Catalyst rely on cmake to do something like find_package(ParaView ...) and link the code against the right libraries. Typically they will rely on finding components like vtkPVPythonCatalyst and vtkParallelMPI and the cmake magic will resolve the rest.
My question is simple: how would I write “by hand” a Makefile that links a code against the right libraries to run with Catalyst? (is that only possible?)
I would not attempt this myself, since the easiest workaround is to have a cmake target within your makefile.
If you do however need this, you can use cmake locally and then attempt to filter through the makefiles that cmake generates and see how far you get with stripping down the content to hand-craft your own makefile.
@ben.boeckel Thanks, this seems to be doing what I want!
Is there a way to locate the paraview-config program from within a CMakeLists.txt file?
What I mean is, after calling find_package(ParaView ...), get the path to paraview-config to be able to call it?
My use case is that of a library compiled using CMake, which depends on Catalyst. My build process creates a .pc file for use with pkg-config from a .pc.in file configured by cmake. I would like to call paraview-config, get its output, and put it in the .pc file when it is generated.
It should be a target, so something like this should work:
add_custom_command(COMMAND $<TARGET_FILE:paraview-config> ${args} > ${output_file})
# another add_custom_command to take the output file and make the `.pc` file for it.
Apparently when using $<TARGET_FILE:paraview-config>, it refers to the paraview-config located in the “lib” directory of Catalyst’s installation path. This executable is dynamically linked against other libraries, requiring me to set LD_LIBRARY_PATH correctly beforehand. The paraview-config executable located in the “bin” directory, however, doesn’t have this problem (no idea why). Is there a way to get the path to that executable instead?
Ooh, forward excutables strike again . On Linux, $<TARGET_FILE:paraview-config-launcher> should work (but just paraview-config on other platforms. Long-term, forward executables shouldn’t be necessary in ParaView, but that’s not the case right now. If you need it to work on multiple platforms if (TARGET paraview-config-target) should do the job to detect which is necessary.
Thanks, that work now. However I’m not sure paraview-config is returning the complete list of libraries needed. When trying to link a program, I get a bunch of undefined references.
Before those undefined references error, I get things like this:
/usr/bin/ld: warning: libvtkUtilitiesPythonInitializer-pv5.6.so.1, needed by /home/mdorier/catalyst/lib/libvtkPVPythonCatalyst-pv5.6.so, not found (try using -rpath or -rpath-link)
(a bunch of other libraries are not found, like libvtkjpeg-pv5.6.so.1, etc.)
Those libraries are not output by paraview-config (yet they are available in Catalyst’s install directory).
Looking at it locally, I do see vtkjpeg in the list. I think the issue with the vtkUtilitiesPythonInitializer is that PythonCatalyst is an odd-ball module (i.e., it doesn’t go through vtkModuleTop). I think the easiest there is just just add vtkUtilitiesPythonInitializer to the list of modules you need.
Adding vtkUtilitiesPythonInitializer doesn’t improve anything (it just adds -lvtkUtilitiesPythonInitializer-pv5.6 to the list of libraries output by paraview-config). To be precise, here is the list of libraries that are missing from the output:
For now, I’d just add them to the paraview-config line manually. With the new module system coming, paraview-config needs to be redone anyways since it can’t get the information it needs from CMake (due to genex stuff and other details).