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

[Friedrich W. H. Kossebau]

Hi,

I need your, the buildsystem experts', help.

In the bugreport https://bugs.kde.org/show_bug.cgi?id=304794 the problem is 
reported that building of Okteta with parallel jobs fails, due to a library 
not created already when it is used to link to, cmp. this snippet from the 
attached log https://bugs.kde.org/attachment.cgi?id=73160 :

--- 8< ---
[ 20%] [ 20%] Linking CXX shared library ../../../lib/libkasten2okteta1core.so
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../x86_64-pc-linux-gnu/bin/ld: 
error: cannot find -lkasten2core
--- 8< ---

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.

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?

Or won't this work anyway because these vars are in different subtrees?

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.

Cheers
Friedrich