[vtkusers] CMake best practice for using VTK?

[Elvis Stansvik]

2016-06-30 14:19 GMT+02:00 Ben Boeckel <ben.boeckel at kitware.com>:

> On Mon, Jun 27, 2016 at 21:44:14 +0200, Elvis Stansvik wrote:
> > 1. The shear amount of libraries that are linked against. Are all these
> > really necessary, or is it possible to more selective somehow? Is there
> > something like Qt's CMake system, where you can pull in just a certain Qt
> > module with target_link_libraries(myapp Qt5::Widgets) ?
>
> Use find_package(VTK REQUIRED COMPONENTS ${libraries_you_want}). Then
> link using ${vtkModuleName_LIBRARIES}. The way you are finding VTK gets
> all libraries.
>

Ah yes, thanks.


> You may also be interested in the VTK_ENABLE_KITS option which reduces
> the number of libraries VTK creates.
>

Alright, I might look into that.


>
> > 2. How come the .so files are specified directly as inputs, with their
> full
> > paths? Isn't the common method to just add the appropriate -l (and
> possibly
> > -L if needed) flags?
>
> CMake prefers full paths. The example is when you have this:
>
>     /path/A/libA.so
>     /path/A/libB.so
>     /path/B/libB.so
>
> and you want to link /path/A/libA.so and /path/B/libB.so. Getting -L and
> -l right is finicky and hard to get right, so just using full paths is
> safer and easier. This usually occurs with setups where you want a newer
> version of A from Homebrew/Macports, but the system B where
> Homebrew/Macports just happens to also have a copy of B.
>

Yep, I actually went to #cmake on Freenode asking about this and got a good
explanation.

I thought that the names contained in ${VTK_LIBRARIES} et.c. were plain
library names (which would result in -l / -L), but realize now that they
are names of imported targets from VTK's installed CMake files, making
cmake generate full paths.

Elvis


>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160630/a5243e80/attachment.html>