Split building

[Alexander Neundorf]

Hi,

On Monday 07 January 2008, Piotr Jaroszyński wrote:
> Hello,
>
> while preparing the 4.0 release in Gentoo we have hit a problem with split
> packages (each app/lib in a separate package, like konqueror, libkonq, kdm
> etc.). To present the problem I will use a concrete example of kdepasswd.
> In order to build it we only unpack apps/kdepasswd (and mandatory files
> from parent dirs like CMakelist.txt from the topdir) from kdebase tarball.
>
> Everything works fine until it comes to linking some libraries, for
> example:
>
> Linking CXX shared module ../../../lib/kcm_useraccount.so
> CMakeFiles/kcm_useraccount.dir/main.o: In function
> `KCMUserAccount::~KCMUserAccount()':
> main.cpp:(.text+0xf4): undefined reference to
> `KEMailSettings::~KEMailSettings()'
> main.cpp:(.text+0x105): undefined reference to `QPixmap::~QPixmap()'
> (lots)
>
> David Faure helped me to track down this problem to CMake being unable to
> expand targets it normally knows when building everything together, i.e.:
>
> apps/kdepasswd/kcm/CMakeLists.txt:
> target_link_libraries(kcm_useraccount konq ${QT_QTXML_LIBRARY}
> ${KDE4_KPARTS_LIBS} ${KDE4_KDESU_LIBS})
>
> CMake cannot expand konq as it doesn't know it's a target in another
> subtree:

I hope I understand correctly.
So the kcm links to the konq library. When building everything in one part, 
the target konq is known as a library and so the kcm will link against it and 
the dependent libraries.
Now the target "konq" doesn't exist, so CMake considers this a library and 
should (I didn't check) add "-lkonq" to the link command.
So it should also in this case link against the installed libkonq.so. 
Shouldn't that work ?
Can you please post the complete link command ?
(run "make VERBOSE=1" to see it)

> apps/lib/konq/CMakeLists.txt:
> target_link_libraries(konq ${QT_QTXML_LIBRARY} ${KDE4_KPARTS_LIBS})
>
> Can you think of any nice solution to this problem? I have only thought of
> keeping a map of deps like konq -> ${QT_QTXML_LIBRARY} ${KDE4_KPARTS_LIBS}
> and sed'ing all the CMakelists, but tbh I don't know CMake too well.

No, please let's find a solution and not go with a hack.
Even if the link command above would work (base "konq" should be interpreted 
as a lib), it would be more or less by accident.
If we can't rely on the fact that the target "konq" exists, then we should use 
something ${KONQ_LIBRARY} and set this accordingly.

These problems only appear when linking libraries which are otherwise also 
built inside the same project, right ?
Are there also other problems ?

Bye
Alex