<div dir="ltr">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 <a href="https://github.com/Kitware/CMake/commit/51ab85c398319c074200ca51f37baa0e4c47ed7c">commit log</a> that adds it suggests that it was not merged into any branch of CMake prior to 3.0.<br><div><br></div><div>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.</div></div><br><div class="gmail_quote">On Wed, Mar 11, 2015 at 10:48 AM Chris Bieneman <<a href="mailto:beanz@apple.com">beanz@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok… I’m sorry. This thread went way out of control in ways I hadn’t anticipated.<br>
<br>
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!).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
-Chris<br>
<br>
> On Mar 11, 2015, at 9:28 AM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br>
><br>
> ----- Original Message -----<br>
>> From: "Renato Golin" <<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>><br>
>> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>><br>
>> Cc: "LLVM Dev" <<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>>, "jroelofs" <<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a>>, "Tobias Grosser" <<a href="mailto:tobias@grosser.es" target="_blank">tobias@grosser.es</a>>,<br>
>> "David Chisnall" <<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>>, "chandlerc" <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>><br>
>> Sent: Wednesday, March 11, 2015 11:25:30 AM<br>
>> Subject: Re: [LLVMdev] [RFC] Raise minimum required CMake version to 3.0<br>
>><br>
>> On 11 March 2015 at 16:17, Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br>
>>> Why? CMake itself already has a bootstrap procedure and associated<br>
>>> scripts? We'd just defer to those as appropriate. The added<br>
>>> complexity is not trivial, but need not be large, and most<br>
>>> importantly, is borne by us, not all other users, packagers,<br>
>>> systems administrators, etc. Plus, having done so, we'll be in<br>
>>> control of what features are available to us, which will provide<br>
>>> an offsetting increase in our productivity. Regarding the other<br>
>>> dependencies you mentioned, they're mostly providing standardized<br>
>>> interfaces (libc, C++11, etc.), except for Python. But Python has<br>
>>> lots of optional external dependencies (ncurses, etc.) and would<br>
>>> not be a good candidate for shipping inline, plus it's large.<br>
>>> CMake's external dependencies are very minimal, and it's not<br>
>>> particularly large, making it a much better candidate for<br>
>>> bundling.<br>
>><br>
>> Ok, I'm out of arguments for this one, but I still don't think we<br>
>> should. :) If everyone else feels strongly about this route, I don't<br>
>> mind.<br>
><br>
> 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.<br>
><br>
> -Hal<br>
><br>
>><br>
>> cheers,<br>
>> --renato<br>
>><br>
><br>
> --<br>
> Hal Finkel<br>
> Assistant Computational Scientist<br>
> Leadership Computing Facility<br>
> Argonne National Laboratory<br>
> ______________________________<u></u>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
<br>
<br>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</blockquote></div>