isolating builds within a module

Alexander Neundorf neundorf at kde.org
Wed Nov 12 23:39:49 GMT 2008


On Thursday 13 November 2008, Aaron J. Seigo wrote:
> On Wednesday 12 November 2008, Alexander Neundorf wrote:
...
> > The time is not "wasted"...
>
> it absolutely is wasted. i spent 90+% of my build time yesterday waiting
> for checks on non-libplasma. not one of those checks resulted in any
> building of any other code that was being checked ..... because they
> weren't changed!

How should the buildsystem know without checking that ?
The time is spent to ensure your build is correct.

...
> unless those checks could be made an order of magnitude faster (in which
> case it wouldn't mater), 

The algorithm was changed from O(n^2) to O(n) [n being the number of source 
files] IIRC last year, so this is in cmake 2.6.x.
So, it checks what it has to check, I would suspect it cannot be made faster 
by magnitudes (at least the algorithm should be more or less optimal 
already).

I measured it here on my system (quite old already), I guess on a recent 
system it's at most 50% of that:
"make plasma" without any changes: 11 s
"make plasma" with modified runnermanager.cpp: 19 s
"make plasma/fast" without any changes: 0.5 s
"make plasma/fast" with modified runnermanager.cpp: 7 s 

We might check whether automoc4 introduces some delay which could be 
minimized. 
Ok, done that:
"make plasma" without any changes and without automoc4: 8 s
I'll check with Matthias.

Maybe libplasma links to something it doesn't need ?
I had a quick look, it links explicitely against threadweaver and knewstuff2, 
so these two are ok and the others (kdecore, kdeui, etc.) anyway. So, it 
seems nothing checked by accident here.

You could also just compile the current file (make foo.o), but, yes, I know, 
as long as everybody is used to just type "make" this is no real solution. 
vim and emacs probably have a shortcut to do this ?

How about making it possible to build plasma as a separate project ?

> is there any way to tell cmake "always build this 
> component with /fast?" when i run cmake for the first time? then it becomes

You mean like a cmake switch to make the fast targets the default ones ? This 
doesn't exist currently.
I'm also not sure the cmake developers would accept a patch, since this would 
mean some people who didn't remember that they are building without full 
dependency checking because they disabled it once will end up with broken 
builds from time to time, and this is something the cmake developers usually 
want to avoid. They basically always prefer reliably correct to fast.

Alex




More information about the kde-core-devel mailing list