[LLVMdev] [cfe-dev] RFC: Upcoming Build System Changes

[Óscar Fuentes]

Daniel Dunbar <daniel at zuster.org> writes:

>>> In LLVM, we have a lot of domain specific structure in the project.
>>> *Any* build system is going to have to codify that information.
>>
>> Both builds systems already support that information. So...?
>
> It isn't explicit,

Yes, it is. At least on the cmake case. You have there file lists,
library dependencies and project settings. I doubt that creating a
parser for that (if you insist on the "readable by an external tool"
requirement) would be much more difficult than parsing your shared file.

> and it is duplicated. Effectively we current have
> two (simple) DSLs embedded in Make and CMake.
>
> The main thing I am proposing here is to just share that information
> in one external documented DSL.

My reading of your proposal makes me think that you plan to shift a
large part of the "intelligence" to the Python scripts. I'm afraid that
you'll learn that that may turn good results in the makefile case, but
not in cmake.

[snip]

> Why? Having an independent self contained (and validated) format
> should be much more obvious exactly what is supported.

CMakeLists.txt is validated too. Not so strict but you can put in place
a coding style that makes the files parser-friendly.

[snip]

> But it means separate implementations. I don't like having duplicate
> implementations of functionality. I want the LLVM project build to be
> as identical as possible, regardless of the build system.

I'm repeating myself, but again: if I'm understanding you correctly,
interfacing your system with cmake will be far from trivial. It will
require lots of changes and additions to the current cmake build.

[snip]

> What I meant here was if someone else needed to use another build
> system for some reason (company mandate, weird OS, whatever), it would
> be very hard for them to deal with the project if all we supported was
> CMake (and they couldn't use it). If we explicitly specify the project
> structure in a documented format, I think it would be easier for
> someone to deal with this.

You are assuming that they will not be happy with any of the multiple
generators cmake supports (we already know about the problems with
Xcode, but AFAIK `make', Eclipse and Visual Studio are well supported; I
don't know about the rest) and that will be easier to connect their tool
of choice with your system that rolling their own spec from scratch or
parsing the Makefile's/CMakeLists.txt already in place.

[snip]

>>>     (c) This doesn't solve any other nice problems:
>>>           (i) It doesn't make it easier to play with other build
>>> systems (like Ninja, or gyp).
>>
>> Do we need them?
>
> No, but I like having more flexibility.

I recall a discussion on the cmake ml about adding support for one of
those tools (can't say which.) At then end, if a build tool is popular
enough it will gain support from cmake.

Really, your plan is to roll the LLVM equivalent of cmake: a spec for
generating build scripts for other tools. So we would end using a build
generator from within a build generator... weird, uh?

[snip]

> At this point, I think it would be easier to have a positive
> discussion once the system I propose is actually in place.
>
> I think the best thing is for me to just roll out the system, so it is
> actually concrete what I am proposing.
>
> I am pretty confident that it will be a net win for LLVM developers,
> but if after things are in place people don't like it, I will gladly
> rip it out. Similarly, if people like it but CMake users find the
> Python dependency egregious, then we can implement support for
> manipulating the LLVMBuild.txt files directly in CMake.
>
> I don't plan (modulo bugs) to break anything in the process, so I
> don't see any harm (aside from wasted time) in taking a "try it and
> see if we like it" approach.

There is an expression for describing this approach: fait accompli.

I'm pretty sure that at first the system will work well, thanks to your
effort. But I'm concerned about long time effects, when you will not be
around to quickly fix the bugs or implement new requirements. By then,
removing your system will be something much more complex than reverting
a few commits in svn. IMAO the result of this would be a less flexible,
reduntant, more complex build system for LLVM.

Would you proposal exist if the cmake language were nicer (not more
powerful, simply neater) ;-)