[LLVMdev] RFC: Upcoming Build System Changes

[Chris Lattner]

On Nov 1, 2011, at 6:41 PM, Óscar Fuentes wrote:

> Chris Lattner <clattner at apple.com> writes:
> 
>>> You keep repeating that and I say that it is wrong. Can you mention a
>>> serialization point on the LLVM build caused by recursive make?
>>> (GenLibDeps is not such example, as described on a previous message.)
>> 
>> Any use of DIRS is a serialization point.  For example, lib/Support ->
>> lib/TableGen -> utils are all built in serial before anything else is.
> 
> AFAIU DIRS is used for lib/Support an lib/TableGen because the latter
> depends on the first. This is not relevant on static builds (or shared
> builds on Linux, IIRC) so, if the `make' scripts were smart enough, that
> case of DIRS could become something like PARALLEL_DIRS_IF_STATIC. That
> would make possible to compile the source files of both libraries at the
> same time. BTW, the cmake build did that (don't know if keeps doing it
> after the switch to explicit dependencies.)

Hi Oscar,

Forgive me, but I've lost track of how any of this has to do with Daniel's proposal. Recursive make vs not, make vs cmake all don't actually matter to his proposal.

His proposal is basically "cmake isn't going to replace make any time soon. We'd like to improve the make system (e.g. by eliminating autoconf) and the first step is to factor redundancy that exists between cmake and make".

While you might *want* cmake to replace make in the near term, it just isn't going to happen.  I don't see how his proposal actually makes our system cmake worse, and all of your arguments seem to trying to convince everyone that cmake is better than make.  What is going on here?

-Chris