-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VTK library name changes #113
Comments
May well be easier to switch from autoconf to cmake. The learning curve is far easier than autoconf. |
So digging into this some more, this seems to be entirely vtk's fault. vtk indeed now inserts a version number at the end of the lib name /before/ the .so. To suppress this you can add -DVTK_CUSTOM_LIBRARY_SUFFIX='' in vtk's configure, but that of course leaves the package maintainers in the dilemma: if you suppress the ugly non-standard naming scheme, you break third-party software (like us) that expect vtk to be built in the default way. See a.o. this discussion https://bugs.archlinux.org/task/43378. So we should expect different distro's to have different solutions. As far as I can see there's no way to find out how it's been build, even if we were using cmake. The value of VTK_CUSTOM_LIBRARY_SUFFIX that's been used isn't set in any of the cmake files that come with Debian's build for instance and neither is it in centos' rpm (which does set -DVTK_CUSOM_LIBRARY_SUFFIX=''" in the .spec of the source rpm). |
That's a nice piece of blackmail then: use cmake as your build system and have code that will work with a script like
Otherwise, write an autoconf script to try every possibility of custom suffices. |
And this is why I eventually gave up and started just using cmake for everything. |
See the thing is - I don't see how it would work with cmake: as far as I can see you would have to know the setting for VTK_CUSTOM_LIBRARY_SUFFIX that was used. The accompanying cmake files just repeat the logic that if VTK_CUSTOM_LIBRARY_SUFFIX is not set, it defaults to |
Kiteware maintain both vtk and cmake - and therefore insure that the "current" cmake supports the current VTK. If cmake is not detecting vtk it's typically because you have a older version of cmake relative to vtk. |
Ah sorry I see now: I was looking in the wrong place. Yes, looks like that should just work indeed. |
Ok, so what about this: For include flags we run (from configure):
and for lib flags:
(substituting Fortran with CXX where appropriate). |
After a little experimenting, @stephankramer's solution can be made robust for those with multiple installations by ensuring that VTK_DIR is set, either as an environment variable, or as a cmake macro cmake --find-package -DVTK_DIR=/strange/path/to/library/cmake/files -DNAME=VTK -DCOMPILER_ID=gcc -DLANGUAGE=Fortran -DMODE=LINK so I think it's a useful way to proceed, assuming that the extra graphical libraries it might pull in to link don't give people problems. |
This is closed by #125, except in the various ways distributions have managed to break their own packages, which @tmbgreaves has discovered. |
It's unfortunately somewhat distribution dependent, but in general you shouldn't be seeing that if you have cmake installed and it can find your VTK installation. (i.e. if |
As was raised in the AMCG Fluidity developers meeting, the current configure script doesn't support the default namescheme chosen for VTK libraries in (at least) version 6.2 and 6.3, as used in unstable versions of debian. An example of a workaround method is available here: 32eb490 however this is itself incompatible with the centos packages for VTK 6.1. The intention is to extend the existing autoconf scripts to include all reasonable namings.
The text was updated successfully, but these errors were encountered: