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

Zachary Turner zturner at google.com
Mon Mar 16 11:00:33 PDT 2015

Adding one more thing to this discussion.  As far as I can tell, CMake 3.0
is the first version to support CMAKE_CXX_SIMULATE_ID.  The clang-cl
self-host build currently depends on this, as there's no other way to
detect that we're building with clang-cl as opposed to MSVC without this.
This feature still seems to be kind of undocumented though.  I don't see it
in any of the release notes for any version of CMake, but the commit log
adds it suggests that it was not merged into any branch of CMake prior to

We can always just say "if you want to self host, you need 3.0 or higher",
but thought I would add this to the thread anyway.

On Wed, Mar 11, 2015 at 10:48 AM Chris Bieneman <beanz at apple.com> wrote:

> 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 or later due
> to bugs in earlier builds of CMake. The patch raising the minimum required
> version to 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, 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150316/094722bf/attachment.html>

More information about the llvm-dev mailing list