Build project setup question

Development
1

For some plugins that I intend to write, I need to pull in the libgeotiff library into my Paraview custom application. I can even find a libgeotiff repository that already uses cmake, and I can try to compile it - standalone. Did not work at first, but I stopped the exercise because I actually do not need this: I want the thing as part of my application!

Now libgeotiff needs two libraries that are already part of Paraview: libtiff and libproj or proj4. So basically I could tell libgeotiff that it can find the required symbols there - but how do I achieve this?

In the existing libgeotiff cmake setup, the libraries are found with find_package - and this (on a Windows system) pulls in the tiff and proj libraries that I have on my system at C:\OSGeo4W64. They would even fit, compiled with the same MSVC compiler and all, so should work. But finally I will have to bring the entire thing into my “superbuild”, so I do not want to rely on these local libraries.

So what I could do in the CMakeLists.txt of my libgeotiff as part of my custom project: first do a “find_package” for paraview, in order to get a number of path variables etc. And then calculate some “HINTS” for the find_package for libtiff and proj4. - derived from the paraview source or target path.

From the find_paraview I am getting e.g. the following definitions:

PARAVIEW_CMAKE_DIR=C:/dev/pv/src/CMake
PARAVIEW_CONFIG_TARGETS_FILE=C:/dev/pv/rel/ParaViewTargets.cmake

With these I could now find the path to both the tiff and the proj library - in the source and the target file tree. And with this generate some “HINTS” to tell the libgeotiff where the libraries can be found…

I am afraid that all this reasoning is far from how things are supposed to be used!

Or maybe there are no ways “how it is supposed”? In that case I could just directly generate some variables like LIBTIFF_INCLUDE or LIBTIFF_LIB and use them in the libgeotiff cmake.

2

Just found this:

get_cmake_property(_variableNames VARIABLES)
list (SORT _variableNames)
foreach (_variableName {_variableNames}) message(STATUS "{_variableName}={{_variableName}}")
endforeach()

Looks like this “trick” will be rather helpful with my questions - because basically I never really know what is actually available in a CMake script after a FIND_… call: the docs only tells me that “it is up to that module” what it has to export. Which makes sense of course…

3

Now libgeotiff needs two libraries that are already part of Paraview: libtiff and libproj or proj4. So basically I could tell libgeotiff that it can find the required symbols there - but how do I achieve this?

If ParaView is built with its own libtiff and proj4, just use whatever libgeotiff wants. If ParaView is using external versions, libgeotiff should agree with ParaView on what’s being used. When built into ParaView, the libraries and symbols are mangled so as to not conflict.

Or maybe there are no ways “how it is supposed”?

If you truly want to agree with ParaView, modifying libgeotiff to use the libvtktiff and libvtklibproj libraries and use the vtk_tiff.h and vtk_libproj.h headers instead of the standard headers, that would be the way to do it (it’d be how libgeotiff would be integrated into ParaView should it ever happen).

Looks like this “trick” will be rather helpful with my questions - because basically I never really know what is actually available in a CMake script after a FIND_… call

ParaView now documents the available variables in the comment at the top of paraview-config.cmake, though I suspect you’re using not-master here. Anything not in that list (or mentioned by CMake find_package documentation) is not guaranteed to be set or available.

4

Thanks for the explanations! This is the status of my work on the subject now:

  1. Regarding libgeotiff, I was aware of the possibility to just link it with own (duplicate) versions of libtiff and proj4 because I read these remarks about some different mangling within the Paraview project. But the background of my question was indeed in your second answer: try to make libgeotiff part of my own Paraview custom application - following the “Paraview/VTK standards” as much as possible. First because I believe that I will have less trouble to integrate my work, and second because I simply love it if code is following some logic and not just “hacking” something into an existing concept that I only understand half-way…

  2. This means that in order to “integrate” libgeotiff, I should make it a kind of “VTK module”, like it was done with libtiff for example. Which means that I have to understand the logic of these “modules”. Which looks like a good idea anyway because I saw that Paraview is also changing to that concept - and I assume that I will eventually have to change also the setup of my own entire project in that way. So I should better start a bit to understand how it is working: at first it simply looks “more complicated”, but more clarity regarding what depends on what etc. is definitely also a good idea.

  3. For my initial problem I found a better solution in the meantime: I found out that the GDAL reader that is already part of VTK is doing already the things that I intended to do with the geotiff library: find the georeferencing coordinates etc. of a Geotiff image! Which means that I do not follow that geotiff track any more now…

Still the entire exercise was valuable, for two reasons:

  1. a little lesson about “VTK modules” - but this learning is not finished yet I am afraid…

  2. that little piece of CMake code that simply dumps “everything”: It is simply a HUGE difference if you can see at a given point in a CMake script what you have and what not! Otherwise all these fancy automatisms like “find_blabla” etc. are more or less useless - because you still do not know what they will give you…

5

a little lesson about “VTK modules” - but this learning is not finished yet I am afraid…

Well, this has changed on master, so I wouldn’t spend too much time studying 8.2’s code here. That code was started in VTK 6 before CMake had all the usage requirement logic it has today doing that, but not as well (because it was limited to CMake code rather than everything CMake itself has access to). The code on master fully uses CMake’s usage requirement features to do things like propagation of include directories and such. The novelties are in the third party library management, exporting information for wrapping later, as well as some other features for making better find_package files.