Switch the build system to CMake

[cofleury]

I was wondering if switch to cmake wouldn't make building on windows easier specially to build it with msvc. As of llvm 3.9, autotools support will be remove so it's needed if we still want to use llvm.

[steveklabnik]

IIRC, @alexcrichton is actively working on re-doing the build system to Cargo.

[cofleury]

Ok but that way we will need Cargo and CMake (because of llvm). So why don't just switch over to CMake ?

[hanna-kruppe]

Why eschew Cargo? It's the tool for compiling crates. CMake doesn't have Rust support so far AFAIK, and if it ever gets Rust support it can't possible get better at it than Cargo. Besides, it's not exactly an extra dependency, since Cargo is part of any Rust installation that is worth being called such.

Now, there are parts to the build system that are outside the domain of Cargo (for example, the entire configure script, and the whole bootstrapping orchestration). Currently those are written in shell scripts and makefiles, and they could conceivably be written in CMake. On the other hand, those operations aren't directly supported by CMake either, i.e., would need lots of custom actions in yet another weird domain-specific language that would perhaps still require external tools (e.g. for downloading stuff). Therefore I am doubtful whether this is the nicest route and whether it will completely eliminate the mingw dependency.

[cofleury]

According to this thread moving to lld will require CMake: #9367 (comment) .

[hanna-kruppe]

If I read that correctly, LLD needs to be built with CMake. But in the near future we'll have to build LLVM as a whole with CMake anyway. There is no way around using CMake, the only question is what we use it for and what not (i.e., what will be done with tools other than CMake).

[cofleury]

I'm ok with the fact that configure and shells scripts are good and can do all lots of things that CMake natively, but that's not completely impossible with some CMake scripts, we can do almost everything we are currently doing. And as i said, it will make use of msvc easier.

[alexcrichton]

Yeah I have an active branch which I hope to PR in the next few weeks to build the entire distribution with Cargo and carve out a huge chunk of our makefiles and configure script. It won't do literally everything that's supported right now, but it should be a big step forward! As part of this transition I'll be moving our LLVM build to cmake (as well as compiler-rt on all platforms), and otherwise I agree with others that are pretty unlikely to rewrite our entire build system in cmake.

As a result, I'm gonna close this for now as there's not a whole lot actionable. Changing our LLVM build to use cmake will happen naturally as we update it and otherwise we're going to rewrite things in Rust/Cargo rather than CMake instead of makefiles.

Thanks for the report though!

@alexcrichton: Has the use of a custom package manager been publicly justified, and where might I find that justification?

I am reluctant to use crates because in my experience all new languages have had poor track records with customized package managers. They are not as secure or as feature-rich as existing solutions, though they immediately achieve better language integration.

In some cases there are glaring security issues. In the case of Haskell's Cabal, code was downloaded insecurely (over HTTP) and run as root, and packages were not checked for authenticity. Can a case be made for the security of Cargo? How does Cargo's security compare to e.g. Gentoo's Portage?