[LLVMdev] RFC: Upcoming Build System Changes

David A. Greene greened at obbligato.org
Tue Nov 1 12:34:04 PDT 2011

"Marc J. Driftmeyer" <mjd at reanimality.com> writes:

> Then this complaint about build times and extra CPU cycles when you're
> living in a world of systems soon to average 16GB of RAM, 4-12 cores
> and GPUs that would make any old Animator dream back in the '90s
> really makes me laugh.

The way the LLVM Makefiles are written prevents use of those 4-12
cores.  Make literally cannot see the parallelism.

I don't know how that works in the CMake world.  I avoid it whenever

> Reinventing the wheel 50 ways instead of improving the wheel until
> it's consistent, clean and easily extendable by third parties seems to
> be a worthy endeavor.

But CMake is a broken wheel.  It always has been.  The fact that it
generates recursive Makefiles is a big clue.  I believe it is
fundamentally architected incorrectly.  The whole premise is wrong
because it's a meta-build system.  The last thing we need for a process
as simple as "build" is lots of indirection.

Now, nothing Daniel is proposing really addresses that but he doesn't
intend to.  He just wants to make builds simpler and faster.  I for one
am all for that.

But don't claim CMake is well-designed, clean and easily extensible.
It's not.

> With all the brilliant minds on this list, you'd think they'd be able
> to coordinate a Proposal to improve Cmake upstream and provide a
> solution all parties could love.

That's imposing an upstream dependency that LLVM does not want to have.
LLVM has different goals and those are going to conflict with the goals
of CMake's upstream.  It would be a nightmare to get parches approved,
for example.


More information about the llvm-dev mailing list