[LLVMdev] RFC: Upcoming Build System Changes

[Óscar Fuentes]

Chris Lattner <clattner at apple.com> writes:

>> 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,

I asked thrice, and got vague responses about bizarre use cases (walking
the set of source code files, organizations creating their own build
systems for LLVM based on exotic tools, and so on.)

At the end, Daniel posted some description and I argue on top of what he
published.

> you
> just adamantly criticized the first micro step.  Fortunately, things
> are about to get a lot more concrete :)

[snip]
  
> 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.

Well, dictate a set of requirements then. Detaching Clang from LLVM (so
Clang can build standalone using LLVM as an external dependency) was
done as soon as someone asked for the feature. I'm confident that the
same would apply to what you have in mind, if you describe it.

(That's rhetoric speech, of course, because it seems that a different
route was already taken and because I'm no longer the maintainer of the
cmake build. All this doesn't diminish the truth that it contains,
though)

[snip]

>> 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.

I'm using the knowledge about his system that was made available so far
and my experience as the author of one of the two LLVM build
systems. Getting the library dependencies (and EH/RTTI settings if you
wish, plus other information contained or containable in the Makefiles)
from cmake is a piece of cake: maybe 20 or 30 lines. And I'll venture
that implementing your "component-aware" build would take no more than
half-day. As his system has to interface with make and cmake, I'm pretty
*sure* that that alone requires modifications to the cmake and make code
that dwarfs the features I mentioned. And then there is the Python code.

> 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?

I'm not on a position to oppose anything. I'm just a concerned
user. I'll like to think that if some day I run the build on VC++ and it
fails, I'll be able to fix it with a reasonable effort. And, to be
honest, I'll admit that the programmer in me suffers when he sees how
people makes a bad implementation of their own stated requirements.

>> 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.

Manual maintenance of library dependencies on both builds -> duplicate
effort -> Daniel's system for removing it.

[snip]