Hello, On trečiadienis 29 Vasaris 2012 22:43:35 Mathieu Malaterre wrote: > reopen 661676 > thanks > > Package was reassigned to vtk. Please do not close until it is > actually fixed. I need to find some time. Thanks.
Ok. Sorry, I didn't check before closing. > On Wed, Feb 29, 2012 at 9:34 PM, Modestas Vainius <[email protected]> wrote: > ... > > > The problem is referring to external libraries which don't use cmake. As > > Brad already explained, since cmake was told to link (and export via > > INK_INTERFACE_LIBRARIES) libz as /usr/lib/libz.so, it did so. If you tell > > cmake to link libz as -lz, it will do so as well. This way -lz will also > > finally end up in IMPORTED_LINK_INTERFACE_LIBRARIES. On the other hand, > > probably most Find*.cmake modules find external libraries as full path > > rather than as -l syntax (unless the library uses pkgconfig I suppose). > > > > So there is no magic here, cmake simply does what it's told to do. Unless > > you are proposing to magically s,/usr/lib/lib,-l, behind the scenes > > (which would be a very bad practise IMHO), I don't see what cmake can do > > here. > > Contrary to you, I do not believe this is so trivial and IMHO a *lot* > of debian packages -today- are using the default cmake mecanisme (eg. > find_package(JPEG) ). They will will be bitten by this soon. However, basically none (with expection of VTK and KDE probably) *exports* them via LINK_INTERFACE_LIBRARIES. Plain linking with full path is no-issue, exporting such a path is an issue so it needs extra care to implement right (VTK has a long history of doing it wrong though). > As a side note Brad's description does not take into account case > where find_package(BLA) internally calls find_package(FOO) which is an > implementation details, as such we will be bitten by this without > notice. Why would such a transitive dependency need to end up in LINK_INTERFACE_LIBRARIES? Unless VTK exposes interface of the external library (in the perfect world it shouldn't), the library should not end up in LINK_INTERFACE_LIBRARIES. Probably you need to carefully review what VTK puts to LINK_INTERFACE_LIBRARIES and remove useless stuff. > Finally Brad's description does not take into account issues such as this > one: > > ... > # Import target "vtkGraphicsJava" for configuration "RELEASE" > SET_PROPERTY(TARGET vtkGraphicsJava APPEND PROPERTY > IMPORTED_CONFIGURATIONS RELEASE) > SET_TARGET_PROPERTIES(vtkGraphicsJava PROPERTIES > IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE > "vtkGraphics;vtkFilteringJava;/usr/lib/jvm/default-java/jre/lib/amd64/libja > wt.so" IMPORTED_LOCATION_RELEASE > "${_IMPORT_PREFIX}/lib/jni/libvtkGraphicsJava.so.5.8.0" > IMPORTED_SONAME_RELEASE "libvtkGraphicsJava.so.5.8" > ) > ... And cmake could do about this? Just remove /usr/lib/jvm/default- java/jre/lib/amd64/libjawt.so from LINK_INTERFACE_LIBRARIES and be done with it. I think it is quite sane to imply that caller should specify java version it needs (in this case at least). > So again I do not believe we can close so easily this bug. Yep, we can't. But the ball is on the VTK side. -- Modestas Vainius <[email protected]>
signature.asc
Description: This is a digitally signed message part.
