[LLVMdev] RFC: Upcoming Build System Changes

[Chris Lattner]

On Nov 2, 2011, at 5:30 PM, Óscar Fuentes wrote:

> Chris Lattner <clattner at apple.com> writes:
> 
>> 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.
> 
> One of the problems with Daniel's proposal is that besides addressing
> the duplicity issue, it has no applications to back it up. The things
> mentioned so far are either extremely vague, or offer dubious gains
> (i.e. removing recursivity from the Makefiles) or trivially done without
> his system (i.e. walking the source files, etc.)

I don't think this is fair.  You never asked what the plan is, you just adamantly criticized the first micro step.  Fortunately, things are about to get a lot more concrete :)
 
>> 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".
> 
> Does that make sense at all? How is autoconf related with duplicity in
> cmake? If he thinks that cmake and autoconf platform tests are
> duplicated, he will be disappointed when he discovers that cmake depends
> on those tests not only for configuring the LLVM headers, but for doing
> lots of stuff. Re-implementing autoconf is a daunting task (if that's
> what he wants to do). Shifting to his system all the decisions that
> depends on those tests is going quite a stretch further.

A big part of the problem not solved by either current cmake or makefile system is that we don't have a good way to decompose LLVM into smaller parts.  We have a notion of reusable components, but these are not exposed in a useful way in the build system.

>> While you might *want* cmake to replace make in the near term,
> 
> No, I don't want that. Somebody suggested that having two build systems
> is a problem, so I retorted that if one of them must stay, is the cmake
> system, for obvious reasons.

Ok, glad we're on the same page then.

>> 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?
> 
> I'll repeat again: Daniel's proposal means adding a lot of complexity to
> the build(s),

How do you make this assessment? You haven't seen the code?  It seems to me that you're jumping to a lot of conclusions based on your assumptions that may or may not be real.

> With all due respect to Daniel: I'm convinced that he is doing this
> because he loves to program Python and considers CMake "horrible"
> (that's the word he used) but he's not doing a favor to LLVM with this
> contribution. That's not the case of *replacing* a dinosaur like DejaGNU
> with something more convenient (as he did.) He is *adding* a lot of
> stuff. He is proposing a cruise missile as a means to kill a mosquito.

This is also the first step of a bigger plan.  Daniel is willing and available to improve the build system in a number of ways, are you opposed to all future improvements?

> Related to this, I'll reiterate my opinion about the explicit library
> dependency issue. What you want is to force the user to know and approve
> the dependency changes his modifications to the source code
> causes. That's orthogonal to maintaining the dependency info up to
> date.

I don't see how this is relevant to the discussion.

> We begin with a suboptimal decision (forcing the users to manually edit
> files for declaring the dependencies instead of exploiting the automatic
> system for implementing the new requirement) and this creates the
> duplicity problem, which in turn prompts Daniel's proposal, which adds
> even more complexity for addressing a problem that shouldn't be there to
> begin with. Happens too often in engineering projects that lots of
> effort is devoted to solving the problems the engineers themselves
> created, but let's try to avoid doing that on this case.


This seems like an extreme conclusion, I'm not sure what assumptions you're drawing on to get to this place.

-Chris