[LLVMdev] [RFC] Raise minimum required CMake version to 3.0

[Chris Bieneman]

Ok… I’m sorry. This thread went way out of control in ways I hadn’t anticipated.

When I looped Chandler in I was really just looking to see if he had input on the Debian Stable issue that arose because he was the one advocating for supporting Ubuntu LTS. I really didn’t expect this to become a big Windows & OS X vs Linux discussion (sorry Chandler!).

Parallel to all this I went out last night and started playing with trying to use the new CMake features to make the compiler-rt build better. What I found was disappointing.

Turns out CMAKE_SYSROOT is (IMO) actually a pretty broken option. It only controls the --sysroot compiler flag. Also, oddly enough the CMAKE_OSX_SYSROOT flag (which I think is poorly named) controls -isysroot. The core problem here is that neither of these options really provides a portable interface for cross compilation. What you really want is a flag that can specify --sysroot (and maybe -isysroot) for gcc, -isysroot for clang, and presumedly something sane for MSVC. Today CMake doesn’t have that, so my biggest reason for wanting CMake 3.x just evaporated.

I’m going to follow up with CMake and file a feature request for a new CMake option for a compiler independent way to specify sysroots. In its absence making compiler-rt cross-compile properly is actually a much more complex problem because we’ll have to come up with a compiler-independent scheme for cross compiling. I expect that this will be through aggressive use of CMake toolchain files. Whoever tackles this work will almost certainly need support from multiple members of the community to provide toolchains for various host compilers and target operating systems. I may have time to look at some of the work on the Darwin side, but I can assure you I won’t have time to drive this through to completion.

Also, just to recap, our current minimum required version of CMake is 2.8.8. It is recommended that all Windows users be on 2.8.12.1 or later due to bugs in earlier builds of CMake. The patch raising the minimum required version to 2.8.12.2 was reverted, and there probably isn’t a driving reason to re-land it. We could add a check that if you are building with MSVC we require 2.8.12.1, but I’m not sure anyone cares enough at this point.

I also agree with Chandler that updating for the sake of updating isn’t terribly valuable. As long as we’re all in agreement that we can update if there is a driving reason I’m completely happy with the state of things (and it seems we are pretty violently in agreement here). If Zach, Owen, Mehdi, myself, or anyone else in the community comes up with a use case that justifies updating to CMake 3.x we can have that discussion when it comes around. Until then how about we let this dog go back to sleep?

-Chris

> On Mar 11, 2015, at 9:28 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> ----- Original Message -----
>> From: "Renato Golin" <renato.golin at linaro.org>
>> To: "Hal Finkel" <hfinkel at anl.gov>
>> Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu>, "jroelofs" <jonathan at codesourcery.com>, "Tobias Grosser" <tobias at grosser.es>,
>> "David Chisnall" <David.Chisnall at cl.cam.ac.uk>, "chandlerc" <chandlerc at gmail.com>
>> Sent: Wednesday, March 11, 2015 11:25:30 AM
>> Subject: Re: [LLVMdev] [RFC] Raise minimum required CMake version to 3.0
>> 
>> On 11 March 2015 at 16:17, Hal Finkel <hfinkel at anl.gov> wrote:
>>> Why? CMake itself already has a bootstrap procedure and associated
>>> scripts? We'd just defer to those as appropriate. The added
>>> complexity is not trivial, but need not be large, and most
>>> importantly, is borne by us, not all other users, packagers,
>>> systems administrators, etc. Plus, having done so, we'll be in
>>> control of what features are available to us, which will provide
>>> an offsetting increase in our productivity. Regarding the other
>>> dependencies you mentioned, they're mostly providing standardized
>>> interfaces (libc, C++11, etc.), except for Python. But Python has
>>> lots of optional external dependencies (ncurses, etc.) and would
>>> not be a good candidate for shipping inline, plus it's large.
>>> CMake's external dependencies are very minimal, and it's not
>>> particularly large, making it a much better candidate for
>>> bundling.
>> 
>> Ok, I'm out of arguments for this one, but I still don't think we
>> should. :) If everyone else feels strongly about this route, I don't
>> mind.
> 
> To be clear, I don't feel strongly about it either. But it seems silly that we spend so much time arguing about CMake version dependencies and have never even discussed bundling.
> 
> -Hal
> 
>> 
>> cheers,
>> --renato
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev