KDE & CMake (was Re: [CMake] the remaining problems with compiling KDE with cmake)

[Alexander Neundorf]

Hi Bill, 
 
thanks for responding :-) 
 
> Von: "William A. Hoffman" <billlist at nycap.rr.com> 
>  
> So, for this list of requirements: 
> Can you explain the ones I have marked with ??? 
>  
> Must support: 
>  - generating binaries (duh)   OK 
>  - generating shared libs (on all ELF platforms + MacOS X; Windows?)  
OK 
>  - icon installation   ??? 
 
Currently the icon directories in the sources look like: 
hi16-app-foo.png 
hi32-app-foo.png 
hi48-app-foo.png 
hi16-app-bar.png 
hi32-app-bar.png 
hi48-app-bar.png 
... 
 
and the Makefile.am: 
 
KDE_ICON = AUTO 
 
which will install e.g. hi16-app-foo.png 
to /opt/kde/share/icons/hicolor/16x16/apps/foo.png. 
 
I guess this should also be possible with some clever cmake macro. 
 
>  - uic, moc, KConfigXT, etc   OK 
>  - GCC visibility   ???? 
 
testing for the version of gcc and add some flag (-fvisibility or 
something like this), so, yes 
 
>  - automatic dependency resolution  OK 
>  - manual hints for dependency resolution  OK 
>  - flex/bison   OK 
 
I didn't find anything yet ? 
 
>  - non-recursive (flat) builds   OK (cmake 2.2) 
>  - --enable-final   ???? 
 
generate a source file which includes all source files, and compile this 
one. This speeds up compilation a lot. Works, see KDEMagic.cmake in 
http://websvn.kde.org/trunk/KDE/kdevelop/cmake/ 
 
>  - builddir != srcdir   OK 
>  - simple to the point of being learnable within 5 minutes  OK 
>  - kdeinit support (?)  ???? 
 
Instead of an application create a shared lib, which can be dlopened() by 
the kdeinit process and then forked and kdemain() executed (makes startup 
of apps faster and uses less memory). Requires generating a source file, 
works, but haven't committed yet. 
 
>  - --compile-slots, like in unsermake  ???? 
 
if I understood this correctly, this is like make -j, but it links only 
in one process, only the compiling works in more processes. This is 
useful for network-compiling (distcc, icecream, etc.). I guess you can't 
do anything about this, since this depends on the buildtool. 
 
>  - pkg-config support   OK 
>  - support rpath sanely   OK 
>  - ability to link & run uninstalled binaries   OK 
 
Can you please explain a bit more ? How is pkg-config supported ? How is 
this linking and running not-yet-installed libs and apps supported ? How 
is rpath used ? 
 
>  - easily integrated into KDevelop    OK 
>  - 'admin' needs to be shipped in KDE instead of in src of each 
app   ??? 
 
Currently each stand-alone KDE app comes with a huge admin/ dir 
containing all the autotools stuff. Usually it is bigger than the actual 
sources. No problem there with cmake. 
 
> I think cmake can do most of this with no problem.   Why is scons the 
> front runner right now? 
 
Ordered by significance (from my impression): 
1) the all-upper-case commands look ugly to several developers 
2) several developers prefer python 
3) there are already some KDE apps using scons (rosegarden I think) 
 
I have another question: 
can ctest be used with svn ? 
 
Bye 
Alex 
 

-- 
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl