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

[Friedrich W. H. Kossebau]

Hi Andreas and Raphael,

Am Freitag, 24. August 2012, 07:15:58 schrieb Andreas Pakulat:
> Hi,
> 
> On Thu, Aug 23, 2012 at 11:58 PM, Friedrich W. H. Kossebau
> 
> <kossebau at kde.org> wrote:
> > I cannot reproduce this locally, but this might be just a timing issue.
> > As this problem has not been reported before, I am currently thinking this
> > could be due to the recent change requested by the Windows
> > groupies^Wbuilders, who asked for setting of the final library name via a
> > property and keeping the internal lib name the same as long as possible,
> > because they would have to update their stuff on a change.
> > (Yes, with Okteta/Kasten the names of the libs change almost every
> > release, to support parallel install of different versions, so simply not
> > changing the name is no option)
> > 
> > So the settings for the library libkasten2core is like this:
> > libs/kasten/core/CMakeLists.txt has:
> > --- 8< ---
> > kde4_add_library( ${kastencore_LIB} SHARED ${kastencore_LIB_SRCS} )
> > set_target_properties( ${kastencore_LIB}  PROPERTIES
> > 
> >   OUTPUT_NAME ${kastencore_LIB_NAME}
> >   VERSION     ${KASTEN_LIB_VERSION}
> >   SOVERSION   ${KASTEN_LIB_SOVERSION}
> > 
> > )
> > --- 8< ---
> > libs/kasten/CMakeLists.txt has:
> > --- 8< ---
> > set( KASTEN_ABI_VERSION   2 )
> > set( kastencore_LIB       kastencore )
> > set( kastencore_LIB_NAME  kasten${KASTEN_ABI_VERSION}core )
> > --- 8< ---
> > So the name of the lib in the buildsystem is "kastencore", while the final
> > libraryname is "kasten2core".
> > 
> > libkasten2core is part of the basic Kasten libraries, these one day should
> > move out of Okteta and become a project on their own, once they matured
> > enough (too many TODOs still, also Kasten and OktetaKasten are developed
> > in sync).
> > 
> > 
> > Now the library "kasten2okteta1core", which builds on the basic Kasten
> > library "kasten2core", has settings like this:
> > In kasten/core/CMakeLists.txt
> > --- 8< ---
> > kde4_add_library( ${oktetakastencore_LIB}  SHARED
> > ${okteta_kastencore_LIB_SRCS} )
> > 
> > target_link_libraries( ${oktetakastencore_LIB}
> > 
> >   ${KASTENCORE_LIBS}
> >   ${oktetacore_LIB}
> >   ${KDE4_KDECORE_LIBS}
> > 
> > )
> > --- 8< ---
> > with this in kasten/CMakeLists.txt:
> > --- 8< ---
> > set( KASTEN_ABI_VERSION 2 )
> > set( KASTENCORE_LIBS  kasten${KASTEN_ABI_VERSION}core )
> > set( oktetakastencore_LIB         oktetakastencore )
> > --- 8< ---
> > So the name of the kasten2core lib, as used in target_link_libraries, is
> > "kasten2core", not "kastencore". That way the buildsystem seems to to not
> > know about the dependency between the two libraries. Especially as these
> > vars are all set in different subtrees, so not seen by the other.
> 
> Good analyzation, thats your bug.
> 
> > So is there a way to make it obvious to the buildsystem that
> > "kasten2core", as listed as link library for "oktetakastencore", is the
> > "kastencore" from above, due to having "kasten2core" as OUTPUT_NAME?
> 
> 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.

Okay, will go with that, if the bug reporter can confirm it solves the problem 
for him, for me this change at least keeps all build variants completing 
without an error.

> or move
> the variable definition up in the tree. Either way you have to create
> a target-level dependency between both targets for cmake to take care
> of the right build-order.
> 
> > When proposing solutions, please keep in mind that I try to keep the
> > different modules as independent as possible, so moving things
> > around/outside will not need big changes in the build system.
> 
> By linking one into another and having it all in the same tree you
> already dropped independency, the oktetakastecore library simply
> depends on the kastencore one.
> 
> 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 :)

Thanks
Friedrich