[cmake-developers] CMake generates Makefiles that don't parallelize as much as they could.

Nick Overdijk nick at astrant.net
Wed Jul 30 11:09:05 EDT 2014


True, I was just bothered by it when we got distcc running with a good
amount of cores. Thanks for your effort. :) I'll try and make something
with the things I've learned (I'm thinking of making some functions that
propagate usage requirements yet link with INTERFACE or something along
those lines, of course only usable for static libs).


On Wed, Jul 30, 2014 at 4:51 PM, Brad King <brad.king at kitware.com> wrote:

> On 07/30/2014 05:31 AM, Nick Overdijk wrote:
> > https://github.com/NickNick/cmake-interface-includes/commits/master
>
> Thanks.  For reference, the summary is:
>
>  cmake_minimum_required(VERSION 2.8.12)
>  project(FOO CXX)
>  add_library(foo foo/foo.cpp)
>  target_include_directories(foo INTERFACE foo)
>  add_library(bar bar/bar.cpp)
>  target_link_libraries(bar foo) # reduces parallel compilation
>  #target_link_libraries(bar INTERFACE foo) # compiles bar without foo reqs
>
> With CMake 3.0 you might be able to hack something up with INTERFACE
> libraries, but that will increase complexity.
>
> The INTERFACE workaround commented out in the above example is really
> only good when no usage requirements need to be propagated.  Otherwise,
> I think you're stuck with the reduced parallelism until CMake can be
> taught to detect when it is safe to drop such dependencies as I
> explained earlier.  FWIW, I've been building large projects this way
> for years and rarely been bothered by this.  Usually each library has
> so many sources that parallelism within each target is enough.
>
> -Brad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140730/b27c1488/attachment-0002.html>


More information about the cmake-developers mailing list