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.k...@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 :)
0001-Work-around-Borland-linker-issue-when-used-with-Ninj.patch
Description: Binary data
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
