[vtk-developers] Use LINK_INTERFACE_LIBRARIES for VTK libs

Brad King brad.king at kitware.com
Wed Jul 29 14:17:54 EDT 2009


Mathieu Malaterre wrote:
> On Fri, Jul 24, 2009 at 4:53 PM, Sebastien
> BARRE<sebastien.barre at kitware.com> wrote:
>> At 7/21/2009 09:14 AM, Brad King wrote:
>>
>>> In order to take advantage of this from outside VTK then the entire
>>> VTKConfig.cmake generation and installation needs to be reworked.
>> That's good news but a scary thought :)  A lot of work went there.
>> Fortunately KWWidgets's dashboard builds itself against both VTK build and
>> install trees, so we should see if something goes very wrong on the VTK
>> side. On the other hand I predict some interesting time for projects like
>> KWWidgets that will need to be compatible with both VTK 5.0 and VTK HEAD,
>> i.e. twos way of exporting libs/packages...
> 
> Brad could you further comment on your comment above Sebastien's ?
> As far as I understand you meant to say, 'in order to take advantage',
> which does not imply there will be backward compatible issue ?
> Transitive linking will not be guarantee when using current
> VTKConfig.cmake, that's all you meant, right ?

Actually transitive linking (kind of) works currently.  It's file-level
dependencies that don't currently work (vtkCommon changes => relink exe).

Switching VTK to export its targets using the new approach should not
require any changes to outside applications to keep them working as-is,
at least for standard use cases.  When an outside project writes

  find_package(VTK)
  include(${VTK_USE_FILE})
  add_executable(myexe myexe.cxx)
  target_link_libraries(myexe vtkCommon)

CMake currently generates a link line for myexe such as

  ... -o myexe -L/path/to/VTK/lib -lvtkCommon

With the new approach it will be

  ... -o myexe /path/to/VTK/lib/libvtkCommon.so

and the make rule will depend on the library file also.

-Brad



More information about the vtk-developers mailing list