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

[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) 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.