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

Raphael Kubo da Costa rakuco at FreeBSD.org
Fri Aug 24 04:02:21 UTC 2012


"Friedrich W. H. Kossebau" <kossebau at kde.org> writes:

> 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}
> )
[snip]
> --- 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< ---

Is there a reason not to link against ${kastencore_LIB} instead of
${kastencore_LIB_NAME}? The target name for CMake is ${kastencore_LIB};
if you pass ${kastencore_LIB_NAME} instead, CMake will interpret that as
a random library that's not being created by this project (with
add_library, for example) and will just pass "-lwhatever" to the linker
and create no depedency between the targets.



More information about the Kde-buildsystem mailing list