kdelibs compile error

[Alexander Neundorf]

On Tuesday 05 August 2008, Ralf Habacker wrote:
> Alexander Neundorf schrieb:
> > On Monday 04 August 2008, Ralf Habacker wrote:
> >> Patrick Spendrin schrieb:
> >>> Ralf Habacker schrieb:
...
> >>>> Short time ago this does work without any problems.  Any  hints how to
> >>>> solve this problem would be very welcome because it is currently not
> >>>> possible to release several important binary packages for the KDE 4.1
> >>>> release.

If it works with cmake 2.4.x, use 2.4.x for building the release packages. 
Installing several versions of cmake is no problem, you just have to use the 
one you want to have when configuring a project initially.

> >>> Exactly the same happens with the general keyword: it is not correctly
> >>> used and thus produces strange errors (trying to link general.lib)-
> >>
> >> The general keyword works for me with cmake 2.6.0 and 2.6.1
> >>
> >>> this seems to be a cmake related problem (maybe a buildsystem one as
> >>> cmake worked with this before).
> >>
> >> When I remove the optimized/debug libraries from the related _DEPENDS
> >> lines in  CMakeCache.txt  and add a
> >> general;E:/daten/kde/emerge-msvc-root/lib/kdewin32d.lib (for debug
> >> builds) then there is no linking error. I assume that there is a problem
> >> in the area where cmake parses the _DEPENDS lines.
> >
> > We really need to get this fixed.
> > It would be cool if you could find out what happens, I didn't have the
> > problem yet on my system. Which buildtype have you set ? Maybe "DEBUG" ?
>
> // CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.
> CMAKE_BUILD_TYPE:STRING=Debug

Does it behave differently if you set this e.g. to MinSizeRel ?

> > The keywords "general", "optimized" and "debug" are handled in
> > ------------
> > cmTargetLinkLibrariesCommand::InitialPass().
> > If there is a way that TARGET_LINK_LIBRARIES() ends up e.g.
> > with "general;kdecore;debug;debug;kdeui;", i.e. two keywords behind each
> > other, then this might cause the problem. The question is, can that
> > happen ?
>
> it is not, see below - I've added from kdecore/CMakeLists.txt
>
> kde4_add_executable(kde4-config NOGUI kde-config.cpp )
> foreach(var ${KDE4_KDECORE_LIBS})
>     message(STATUS ${var})
> endforeach(var)
>
> target_link_libraries(kde4-config ${KDE4_KDECORE_LIBS} )
>
> and run nmake rebuild_cache which gives:
>
> -- E:/daten/kde/emerge-msvc-root/lib/QtCored4.lib
> -- kdecore
> -- optimized
> -- E:/daten/kde/emerge-msvc-root/lib/kdewin32.lib
> -- debug
> -- E:/daten/kde/emerge-msvc-root/lib/kdewin32d.lib
> -- user32
> -- shell32
> -- ws2_32
> -- netapi32
> -- userenv
>
> which looks okay.

This is good so far, but internally cmake does more, which we don't see here.

> > It shouldn't. Can you find out whether that happens there ?
>
> Then I tried to recompile cmake 2.6.1 from zip file to have debug
> symbols. Unfortunally this fails

We need to get this working, and then check in the 3 files I mentioned what is 
exactly going on.
Will you be at Akademy ?

Alex