No subject

files (sonames) that it knows must be found at link time.  It then
inspects the directories containing these libraries for conflicts,
constructs a constraint graph, and generates a safe order for the
directories to be listed with the -rpath-link flag.

> 2. How can i influence it's content?

There is no direct interface for it.  One must give CMake enough
information for the above automatic algorithm to work.  If all the
libraries involved in linking every CMake-built shared library along
the way were brought in as imported targets then it would work.
However, this is not the case for the Qt libraries AFAIK.

For a shared library target CMake distinguishes its link interface
dependencies (or "link interface") from its link implementation
dependencies (or "link implementation").  It computes the set of
shared libraries that go in IMPORTED_LINK_DEPENDENT_LIBRARIES by
identifying shared libraries in the target's link implementation
but excluding those in the target's link interface.  The result
is the set of "dependent libraries".

In the default case the link interface is the same as the link
implementation so the list of dependent libraries is empty. When
LINK_INTERFACE_LIBRARIES is set (which happens in your case) then
the list can be non-empty.  However, it will only every consist
of the libraries from the link implementation that CMake *knows*
are shared libraries.

Currently the definition of "knows" is that the dependent library
is a *target* (imported or built) and not just a file name.  One
can see the code in CMake 2.8.2 in the file Source/cmTarget.cxx
at lines 4222-4245:

http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;h=45ba3584;hb=v2.8.2#l4207

Note the TODO comment.  It does not recognize shared libraries
by file name.  This causes your problem because the file

  /path/to/kde4/trunk/support/libphoton.so

does not end up in the list of known dependent libraries.
Therefore it is not included in the above-mentioned ordering
algorithm and /path/to/kde4/trunk/support does not end up in
the -rpath-link option.

Unfortunately implementing the TODO comment is non-trivial.  CMake
must first recognize shared library full-path file names from the
link implementation list.  Then for each shared library it finds
it must also locate the full path to the file that will be loaded
at runtime based on the *soname* of the library!  In simple cases
the soname is the same as the library, or the library file is just
a symlink to the soname, but in the worst-case we need to know
and understand the library's ABI to parse out the soname.

> 3. Do we have a problem with our LINK_INTERFACE by only being
> able to specify which libs we need and not being able to
> specify where WE took it from? KHTML needs phonon but it does
> not tell me openly.

The KHTML imported target *should* come with libphoton.so listed
in the IMPORTED_LINK_DEPENDENT_LIBRARIES property.  It does not
right now because

- libphoton.so was not imported as a target when khtml was built
- CMake did not recognize it as a runtime dependency of khtml
  due to the lack of implementation at the above-mentioned TODO

> So how am i supposed to make sure it's found?

As a hack, you might be able to add your own -Wl,-rpath-link
option to the CMake cache in the entries

  CMAKE_EXE_LINKER_FLAGS      (to help executables link)
  CMAKE_SHARED_LINKER_FLAGS   (to help shlibs link)

The linker may take both instances of -rpath-link and combine
the paths.

-Brad