cmake

[Alexander Neundorf]

Hi,

On Thursday 08 June 2006 11:14, Stephan Kulow wrote:
> Am Donnerstag, 8. Juni 2006 08:53 schrieb Thomas Zander:
> > I also learned that cmake is in its core nothing but a
> > makefile-generator. 

No, it's not.
It's a "build file" generator, buildfile being one of GNU make, BSD make, MS 
nmake, Borland make, XCode project, MS Visual Studio project, KDevelop 
project.

> > This means that it might be a good idea to resurrect
> > unsermake to sidesteps all of the design flaws cmake has (like being
> > dogslow on big trees).  Any takers? :-)
>
> Let me put some things straight: unsermake is basically a wild hack and the
> lack of people beside me understanding what it is proofs this kind of :)
>
> _Everything_ is dog slow on big trees - most of that is eaten up by IO and
> simply generating the trees and I couldn't feel cmake being slower than
> unsermake actually. What I feel though is lacking is good support for
> subtrees. Developing in kdelibs/kio will look at kdecore even though I
> don't want make to do that - just stealing my time. But this is most likely
> easy to fix and is not a "design flaw".

Yes. If any of the cmake files has changed all cmake files are read and parsed 
again and the Makefiles (or project files etc.) are generated.
I tested a bit on kdebase.
About 20 to 25 percent of the time are spent in automoc.
There are ways to optimize this.
One could write a cmake plugin in C and hope that this gets the job done 
faster than the cmake script. I'm not sure this will be more maintainable.
Or one would have to check all source files and generate some cmake files 
which contain the ADD_CUSTOM_COMMAND() for the moc if required and which are 
included in the main cmake file and which are only regenerated and the C++ 
files parsed if the date of the C++ file is newer than the one of the rule 
file. This will be not too easy.

Leaves us still with 75 percent of the time.
Let's say a file was added in kdelibs/kio/. This comes down to the fact that 
the cmake file has changed which could potentially also have a changed a 
configure check so that the config.h needs to be rewritten. In order to 
rewrite config.h, all variables which are used in config.h need to be known. 
I.e. all cmake files _have_ to be interpreted I'm afraid.
This can probably be also required for other things, not only for configure 
checks, but also for other options.
Configuring and generating both take approx. 50 percent of the time. But maybe 
it should be possible to regenerate only those Makefiles which are required 
for the current build subdir and mark the others only as out-of-date.

> If just I wouldn't love spending my time on real issues, I'd write a XML
> backend for cmake that basically allows running cmake to configure and
> write out high level definitions of the things to build and then you could
> write a script similar to unsermake (you'll use less than 20% of the
> current code if you don't have to care for automake conditionals :) that
> gives the user better control/feedback.

Yes, I also already had this idea, let cmake dump out all its knowledge not in 
Makefiles, but easy (alhtough maybe slow) to parse xml-files which can be 
read by a relatively simple tool written in your preferred (scripting) 
language. I.e. Ruby ;-)
This would even fit well with the cmake concept and "just" be another 
generator.

> And no, I don't think --prefix -> -DCMAKE_INSTALL_PREFIX will stress anyone
> being able to read. Not everyone might compile software for a living, but
> let me assure you: there are almost as many build systems out there as free
> software projects. And if there isn't even a configure script around, then
> you don't have to bear with the expectations for it to conform to autoconf
> (no ./config.status --recheck? --sbindir does not work? --no-create still
> creates? ...)

The idea on the cmake list was to be able to provide command line argument 
shortcut mappings.
Like putting something like the following in a special file which will be read 
by cmake:
MAP(CMAKE_INSTALL_PREFIX prefix)
MAP(CMAKE_VERBOSE_MAKEFILE verbose)

Then users could type "cmake --prefix=/opt/kde4 --verbose" etc.

I also think that pretending to be configure would lead to wrong expectations.

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