cmake

Alexander Neundorf neundorf at kde.org
Thu Jun 8 17:40:59 BST 2006


Hi,

On Thursday 08 June 2006 12:45, Thomas Zander wrote:

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

I handles trees as one big project and since the apps and libs in the tree 
depend on each other I don't see the design flaw in this approach. 

If we modularize or modules stronger, so that the top level CMakeLists.txt 
only lists the subdirs, the user would have the choice to either build 
everything at once from the top level by running cmake on the top level, or 
to build it in parts by running cmake in the first subdirs.
This would also mean that if there is e.g. koffice/lib/ and koffice/kword/, 
and you decide to run cmake on koffice/lib/ and koffice/kword/ separately, 
that in this case koffice would link to the installed versions, not to the 
libs in the builddir.
If this sounds interesting, we can look into this.

...
> But for now, I'd call it a design flaw due to cmakes dependency on POSIX
> make.

POSIX make is just one of the supported generators of cmake.

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

Ok. Where are these 5 minutes spent ? 
Configuring, generating, "make all", relinking ?
How fast is your box ? (I don't want to suggest to upgrade, just for 
reference).

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