internal lib name vs. output lib name, getting internal dependencies?

[Andreas Pakulat]

Hi,

On Fri, Aug 24, 2012 at 10:22 AM, Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
> Hi Andreas and Raphael,
> Am Freitag, 24. August 2012, 07:15:58 schrieb Andreas Pakulat:
>>
>> Yes, don't use the library name, use the target name, i.e.
>> ${kastencore_LIB}. If the variable is not visible at the place of
>> linking you can either hardcode the name in the target_link_libraries
>> (all targets defined in a previously-read CMakeLists.txt are known in
>> later read files regardless of the place in the source tree)
>
> Ah, so that was the missing bit of information, so I can/have to use the
> target name of the base Kasten libs in the target_link_libraries of the Okteta
> Kasten libs, as they are indeed known there to the build system.

Yes, target_link_libraries accepts target names from the same project
or from so-called imported targets (produced by other cmake projects
which simply reference the install-location of the .so) and cmake will
then handle the details of finding the actual .so to link against.

I'd also like to note that giving names of .so files to cmake is most
of the time a bad idea, since cmake cannot create any kind of
dependency then, so for external libs you should either have imported
targets or at least provide absolute paths to target_link_libraries.
That way cmake will at least be able to setup a rule to re-link in
case the library is missing and it'll also bail out if the file is
missing IIRC during cmake time.

>> You're not going to be able to simply take out either sub-tree and
>> move it to a separate source/build tree without doing a few
>> adjustments to the cmake files later on. In particular finding the
>> kasten libs will be different once they're in a separate module, you
>> cannot really fake that easily when both are in the same cmake tree.
>
> Hm, true, but at least I want to be as close as possible to the Kasten-is-
> external situation as possible :)

Having a cmake variable for the target name is a good step towards
that, since you can then provide the same cmake variable from a Cmake
config file for the imported target once kasten is really an external
library. You'd 'just' replace the set(...) with a find_package(Kasten)
in Okteta's cmake code.

Andreas