responses from the cmake developers

Alexander Neundorf neundorf at kde.org
Thu Jun 16 22:28:41 BST 2005


Hi,

some cmake developers responded to the issues KDE has with cmake.
Summary: now cmake supports the commands also in lower case, the integrated 
testing system does work with svn, and it is now able to create libs and apps 
with the same name (as libkdevelp.so and kdevelop).

Here come the emails:

To the list of requirements:

--- Weitergeleitete Nachricht -------------

Von: "William A. Hoffman" <billlist at nycap.rr.com>
An: Alexander Neundorf <a.neundorf-work at gmx.net>
Kopie: cmake at www.cmake.org, neundorf at kde.org
Betreff: Re: KDE & CMake (was Re: [CMake] the remaining
problems        with    compiling KDE with cmake)
Datum: Thu, 16 Jun 2005 10:06:16 -0400

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   ???
 - uic, moc, KConfigXT, etc   OK
 - GCC visibility   ????
 - automatic dependency resolution  OK
 - manual hints for dependency resolution  OK
 - flex/bison   OK
 - non-recursive (flat) builds   OK (cmake 2.2)
 - --enable-final   ????
 - builddir != srcdir   OK
 - simple to the point of being learnable within 5 minutes  OK
 - kdeinit support (?)  ????
 - multiple build targets (libfoo, libbar, libbaz) in one file  OK
 - --compile-slots, like in unsermake  ????
 - pkg-config support   OK
 - support rpath sanely   OK
 - ability to link & run uninstalled binaries   OK
 - easily integrated into KDevelop    OK
 - 'admin' needs to be shipped in KDE instead of in src of each app   ???
   (if we keep the 'admin' dir, that is)


I think cmake can do most of this with no problem.   Why is scons the front
runner right now?

-Bill
-----------8<--------------8<-------------------8<----------------------------

About the problem that cmake can't handle multiple targets with the same name 
(e.g. libkdevelop.so and kdevelop):

----------- Weitergeleitete Nachricht -----------------

Von: "Ken Martin" <ken.martin at kitware.com>
An: <cmake at cmake.org>
Betreff: [CMake] Executables with the same name as libs
Datum: Thu, 16 Jun 2005 14:08:54 -0400

After some more brainstorming it seems there is a better way to handle this.
Basically targets must be unique, but you can change the name of the output
produced for executable targets.  This results in something like


# and two targets in the same dir with the same name
ADD_LIBRARY(mytest2 ../Lib1/libc1.c)

ADD_EXECUTABLE(mytest2_exe conly.c)
SET_TARGET_PROPERTIES(mytest2_exe PROPERTIES OUTPUT_NAME mytest2)
TARGET_LINK_LIBRARIES(mytest2_exe mytest2)


This snippet is from the SameName test I just added into CMake (not enabled
yet). The two targets have different target names but by setting the
OUTPUT_NAME property on mytest2_exe we can make the executable produced be
called just mytest2. I have committed these changes for Makefiles, VS7 and
untested in VS6, although there are probably some gotchas still in there.
This seems much cleaner.

Thanks
Ken

-----------8<--------------8<-------------------8<----------------------------

About the the integrated test system and, bison, flex and other things:

--- Weitergeleitete Nachricht ----------------

Von: "William A. Hoffman" <billlist at nycap.rr.com>
An: cmake at cmake.org
Betreff: Re: KDE & CMake (was Re: [CMake] the
remaining       problems        with    compiling KDE with cmake)
Datum: Thu, 16 Jun 2005 15:11:08 -0400

> - flex/bison   OK

This can be done with some custom commands and macros.   Although for
most of our projects we add the generated source to cvs so that you can
build
it on windows without those tools.   It is easy to make it run them if they
are
present and use the checked in source if not.   We do this when we build gcc
for
gccxml with cmake.

>  - --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.
make -j can do this.  Also distcc can be used with cmake, also with the
Xcode
generator it supports this.  So, if the native build system has it, so do
we.


>> Ordered by significance (from my impression):
>> 1) the all-upper-case commands look ugly to several developers

I think we can change cmake so that upper or lower case commands work.



>> 2) several developers prefer python

Not much we can do about that.


>> 3) there are already some KDE apps using scons (rosegarden I think)
>>
>> I have another question:
>> can ctest be used with svn ?
>>

Yes ctest does work with svn.


So, I guess we need to have the pros of cmake:

1. It works on a standard windows install of visual studio.
I assume scons uses the command line cl which is not configured by default.
Users can use an IDE to build if they want to.

2. CMake has ctest and dashboard support.

3. CMake does not require python to be installed.

-Bill

-----------8<--------------8<-------------------8<----------------------------

About the upper-case commands:

--- Weitergeleitete Nachricht -----------------------
Von: Andy Cedilnik <andy.cedilnik at kitware.com>
An: "William A. Hoffman" <billlist at nycap.rr.com>
Kopie: cmake at cmake.org
Betreff: Re: KDE & CMake (was Re: [CMake] the
remaining       problems        with    compiling       KDE with cmake)
Datum: Thu, 16 Jun 2005 16:17:55 -0400

Hi All,

William A. Hoffman wrote:

>>- flex/bison   OK
>>    
>>
>
>This can be done with some custom commands and macros.   Although for
>most of our projects we add the generated source to cvs so that you can
> build it on windows without those tools.   It is easy to make it run them if 
> they are present and use the checked in source if not.   We do this when we 
> build gcc for gccxml with cmake.
>  
>

Actually CMake has a code in it that uses lex and yacc to generate
cmCommandArgument* files. Look in CMake/Source. It is not used while
building CMake, but you can enable it.

>>>Ordered by significance (from my impression):
>>>1) the all-upper-case commands look ugly to several developers
>>>      
>>>
>
>I think we can change cmake so that upper or lower case commands work.
>  
>

Just implemented. CMake commands are now case insensitive. If you want
to use lowercase, go for it.

>>>3) there are already some KDE apps using scons (rosegarden I think)
>>>
>>>I have another question:
>>>can ctest be used with svn ?
>>>
>>>      
>>>
>
>Yes ctest does work with svn.
>  
>

Fltk uses SVN and we test it every night.

-- 
Andy Cedilnik
Kitware Inc.

--------------8<-----------------8<-------------------8<-------------------

IOW they just implemented what we'd like to have :-)

Bye
Alex
-- 
Work: alexander.neundorf at jenoptik.com - http://www.jenoptik-los.de
Home: neundorf at kde.org                - http://www.kde.org
      alex at neundorf.net               - http://www.neundorf.net




More information about the kde-core-devel mailing list