<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Neil,<div class=""><br class=""></div><div class="">I'm really not sure what you're getting at. Are you objecting to the proposal to update?</div><div class=""><br class=""></div><div class="">The LLVM community operates by having request-for-comment (RFC) discussion threads to coalesce around a plan, then just moving forward. There is no formal argument or proposal needed.</div><div class=""><br class=""></div><div class="">We also don't really have an official policy regarding updating CMake. In your other emails on the thread you were talking about "production" machines, and I don't think the tools required to develop LLVM really factor in there at all. In a production environment you should be using a release of LLVM, likely obtained in binary form.</div><div class=""><br class=""></div><div class="">If you have an objection to the LLVM trunk requiring CMake 3.15.0 in order to build I'd like to understand that objection so that we can take it into account as we move forward.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">-Chris<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 4, 2019, at 7:23 AM, Neil Nelson <<a href="mailto:nnelson@infowest.com" class="">nnelson@infowest.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p class=""><font size="-1" class="">Here is how I would make the argument for the latest version of cmake.</font></p><font size="-1" class=""></font><p class=""><font size="-1" class="">The latest version of cmake addresses a number issues we face in building LLVM including the following.</font></p><font size="-1" class=""></font><p class=""><font size="-1" class="">[list the justifications]</font></p><font size="-1" class=""></font><p class=""><font size="-1" class="">We realize this using of the latest versions of external software goes outside our usual method, but in this case the cmake software will not be folded into the resulting LLVM software release and only in the building of the release. Whatever issues a new cmake may present in the build will be identified during testing in that the nature of cmake should easily allow our standard testing to know if it is working properly or not.</font></p><font size="-1" class=""></font><p class=""><font size="-1" class="">For those building<span class="Apple-converted-space"> </span></font><font size="-1" class=""><font size="-1" class="">LLVM</font><span class="Apple-converted-space"> </span>for standard OS release versions such as the Ubuntu LTS versions seen on our prepared build page, it is expected that those installations are dedicated to the building of LLVM and not for any other production purpose so that installing the recent version of cmake will not affect their other efforts if some problem with this latest cmake version arises.</font></p><font size="-1" class=""></font><p class=""><font size="-1" class="">Neil Nelson</font></p><div class="moz-cite-prefix"><font size="-1" class="">On 11/4/19 7:33 AM, Robinson, Paul wrote:</font><br class=""></div><blockquote type="cite" cite="mid:BYAPR13MB2421619149A5506B58655C21927F0@BYAPR13MB2421.namprd13.prod.outlook.com" class=""><pre class="moz-quote-pre" wrap="">However I think you are creating a false dichotomy. I have no real
insight into Ubuntu's methodology, but as a user, what I observe
is that Ubuntu LTS is NOT a collection of the most recent stable
well-tested versions of all components, kept up-to-date; instead,
it is a snapshot of stable, well-tested versions of all components,
which Ubuntu then commits to maintaining for N years. A given LTS
releases maintenance updates only, not new features.
And it is certainly not the case that every version of every
component after an Ubuntu LTS is a buggy, bleeding-edge untested
hacked-up mess. Ubuntu LTS chooses to stick with certain versions,
not because later versions are awful, but because picking up new
versions is not their goal.
So, when we talk about raising our minimum required CMake version,
it is not to take CMake bleeding-edge HEAD and have everyone build
their own; it is to take a more recent formal release of CMake.
Now, the CMake people might not conveniently package binaries for
everyone's environment, which might mean some people need to pull
a release's source package and build it themselves; this is the
nature of open-source.
--paulr
</pre></blockquote></div></blockquote></div><br class=""></div></body></html>