cmake

[Thomas Zander]

On Thursday 8 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. 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 :)

Well, you still get hugs for make $KDEDIR/lib/mylib.la speeding up my 
workflow considerably while using unsermake :-)

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

The issue is that cmake tries to make all subtrees behave like one tree 
while using a lot of makefiles and with the limitations of POSIX make 
this is just a recipe for failure.  This is the design flaw I'm looking 
at.
The part where I see it being very slow is if you type make in kio it does 
a lot of work outside of that sub-tree.  If the whole project does not 
fit in my cache then I'm stuffed.  So, subtrees were suppost to bring 
independence; cmake throws that out the window.
For more info on that problem:
http://www.cmake.org/Bug/bug.php?op=show&bugid=2389

Maybe some generated temporary dir with a list of hardlinks to all the 
>500 CMake*txt files in koffice can overcome that. That would be great. 
But for now, I'd call it a design flaw due to cmakes dependency on POSIX 
make.

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

:-D

> So please everyone: concentrate on the real issues and forget about
> build tools being able to display progress ;)

I fully agree on the progress thing.
The cmake people promised me to have all targets also have  a target/fast 
version. Where the fast does not do auto-dependency-checking at all.
I'd have to see it to figure out how usefull it is, though.

I'm currently slowed down in my development considerably by missing 
 "* Provide target for making+installing a single library"
It takes 20 seconds in the koffice 1.5 tree to change a small file and 
install the changed lib and it takes 5min (no joke!) to do the same in 
trunk.
For some reason this makes this a 'real issue' for me :-)
-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060608/5f940d54/attachment.sig>