[cmake-developers] [PATCH] Fixed Borland linker issue when used with Ninja generator

[James Johnston]

See updated attached patch.  I've retested it to ensure the VTK 5.4.2 build
I've been working with still builds correctly - and it still does.

Thank you for considering it.

-James

> -----Original Message-----
> From: Brad King [mailto:brad.king at kitware.com]
>
> > +set(CMAKE_JOB_POOL_LINK BCC32LinkPool)
> 
> Hmm.  What if the user sets this too?  Perhaps we should allow
> users/projects to take control of this setting by making the whole block
> conditional:
> 
>   if(NOT DEFINED CMAKE_JOB_POOL_LINK)

Fair enough.  Change made.  I can't think of a real-world reason why someone
would want to do this (given the buggy behavior that will result), but I
suppose it's better not to step in the way.  (The only thing I could think
of would be if you wanted both compiler and linker to use the SAME job pool,
which would then have to be restricted to 1.  At that point, there's no
reason to using Ninja in the first place...)

> 
> > +get_property(_EMB_TMP_POOLS GLOBAL PROPERTY JOB_POOLS)
> list(APPEND
> > +_EMB_TMP_POOLS BCC32LinkPool=1) set_property(GLOBAL PROPERTY
> > +JOB_POOLS ${_EMB_TMP_POOLS})
> 
> This can be just
> 
>  set_property(GLOBAL APPEND PROPERTY JOB_POOLS BCC32LinkPool=1)

Oops, I overlooked that!  Much cleaner now, thanks :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Work-around-Borland-linker-issue-when-used-with-Ninj.patch
Type: application/octet-stream
Size: 2185 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150618/586fd822/attachment.obj>