[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