[cmake-developers] Ninja pools

[Brad King]

On 11/09/2013 06:39 AM, Peter Kümmel wrote:
> On 08.11.2013 17:22, Brad King wrote:
>> Without context the name "POOL" may not have clear meaning to
>> a reader not already familiar with Ninja's feature.  I think
>> a name like JOB_POOL would be clearer.
> 
> Even JOB_POOL leaves the question what a "pool" is.
> I think it would be better to completely drop "pool", and to use
> something more obvious like PARALLEL_JOBS

IMO the name "JOB_POOL" is clear enough.  It is distinct and can
be used to locate information about the feature.

> I would prefer to create a semantic which also fits for other generators
> and not to use the NINJA prefix. How could the limiting be very different
> for other generators? It always reduces the number of parallel processes.
>
> Maybe a property for just disabling parallel execution at all is enough.
> I couldn't imagine use cases where the fine-grained pool control
> of ninja is needed. Such a simplifies interface should also be
> compatible with other generators, and would be very strict, as requested.

On second thought the semantics are already pretty general.  If
needed then future support in other generators could add restrictions
like a max pool size or something.

Since this is still experimental I'd rather not add an option to
add_custom_command for it yet.  Let's just go with global property

 JOB_POOLS

to configure the pools, target properties

 JOB_POOL_LINK
 JOB_POOL_COMPILE
 JOB_POOL_CUSTOM

to map rules to the pools, and variables

 CMAKE_JOB_POOL_LINK
 CMAKE_JOB_POOL_COMPILE
 CMAKE_JOB_POOL_CUSTOM

to initialize the mapping in each target.  A future option to
add_custom_command could override JOB_POOL_CUSTOM but the simple
default will allow projects to quickly group everything without
marking up all their targets or custom commands.

-Brad