[William A. Hoffman]

At 04:29 PM 3/15/2006, David Faure wrote:

>No; our current solution which supports "N compile jobs in parallel but
>only one linking job at a time", is "unsermake". An automake+make replacement,
>written in python, and living in trunk/kdenonbeta/unsermake in the KDE svn.
>A very nice build tool (it has other features that I'll be requesting from cmake
>at some point ;), but with the major disadvantage that it still relies on autoconf
>for the configuration part, so it's no portable solution.

I was wondering what unsermake was....  I suppose we could create an
unsermake generator in cmake, and that could be used to do the parallel builds.

>The actual distribution over a compile farm can be done with distcc or
>with the KDE fork of it, icecream (which has a nice GUI, and an easier setup AFAIK).

However, one idea we are thinking of now, is something like this:

cmake -E WaitForSemaphore semaphore_file
<some cmake command (could be a link, could be moc, or anything else)>
cmake -E ReleaseSemaphore semaphore_file

Then you could use this to serialize any part of the build independent of the build
tool being used.   It would be done with some sort of target or global property that
could be used to insert those commands around any command that needs to be
done in a serial mode.  

Then the semaphore could be initialized with 1 to achieve full serialization, or a higher number to allow up to N of the group to run at once.  That way cheap tasks (distributed compilation) could have full parallelism, medium-cost tasks (moc?) could have a lower level of parallelism, and expensive tasks (linking) could have full serialization.



-Bill