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