Split building

[Piotr Jaroszyński]

On Monday 07 of January 2008 19:01:45 Alexander Neundorf wrote:
> 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.

Yes.

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

Yes.

> So it should also in this case link against the installed libkonq.so.
> Shouldn't that work ?

I thought so too, but I think -Wl,--no-undefined makes it fail (it seems to 
only check direct deps for symbols). See the command line below.

> Can you please post the complete link command ?

/usr/lib64/ccache/bin/x86_64-pc-linux-gnu-g++  -fPIC -O2 -march=athlon64 -pipe  -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -fno-check-new -fno-common -Woverloaded-virtual -fvisibility=hidden -fvisibility-inlines-hidden -O2 -DNDEBUG -DQT_NO_DEBUG -Wl,--enable-new-dtags -Wl,--fatal-warnings -Wl,--no-undefined -lc  -shared -Wl,-soname,kcm_useraccount.so -o ../../../lib/kcm_useraccount.so "CMakeFiles/kcm_useraccount.dir/kcm_useraccount_automoc.o" "CMakeFiles/kcm_useraccount.dir/chfnprocess.o" "CMakeFiles/kcm_useraccount.dir/main.o" "CMakeFiles/kcm_useraccount.dir/chfacedlg.o" "CMakeFiles/kcm_useraccount.dir/settings.o" -L/usr/lib64/qt4 -L/usr/kde/4.0/lib64 -L/lib64 -lkonq -lQtCore -lpthread -lkdecore -lkpty -lkdesu -lkdecore -lQtCore -lpthread -lQtNetwork -lQtDBus -lQtXml -lz -lbz2 -lresolv -lutil -lutempter -Wl,-rpath,/usr/lib64/qt4:/usr/kde/4.0/lib64:/lib64

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

Agreed, I would prefer something sensible too.

> If we can't rely on the fact that the target "konq" exists, then we should
> use something ${KONQ_LIBRARY} and set this accordingly.

Sounds like an idea.

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

Yeah, because CMake doesn't know all the targets.

> Are there also other problems ?

Not that I know of.

-- 
Best Regards,
Piotr Jaroszyński