<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 27, 2016, at 11:17 AM, Renato Golin <<a href="mailto:renato.golin@linaro.org" class="">renato.golin@linaro.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 27 April 2016 at 18:41, Chris Bieneman <<a href="mailto:beanz@apple.com" class="">beanz@apple.com</a>> wrote:<br class=""><blockquote type="cite" class="">Renato, in your most recent email you comment about differentiating *stable* vs random versions of CMake built from source. I believe as a community our recommendation should be that people download CMake sources from <a href="https://cmake.org/download/" class="">https://CMake.org/download/</a> instead of git. Then they get the source of a known stable release. If people choose to pull random git hashes or tags, that is their decision, but since the minimum version I'm proposing is widely available I think it will be uncommon.<br class=""></blockquote><br class="">I'm guilty of cloning the git repo on my local tree, because it's<br class="">easier to do that than to find the link, download, untar, clean up,<br class="">etc. Then there's a bug, and you need to upgrade, "git pull" is much<br class="">simpler than repeating the whole process again. :)<br class=""><br class="">Also, recent "stable", as Chuck has shown, is less stable than<br class="">previous stable. I'd like to err in the side of caution.<br class=""><br class=""><br class=""><blockquote type="cite" class="">I've been working to try and un-do the horrible Darwin approach we have because I think it has some serious problems, but an alternative solution would be to extend the Darwin approach to every other platform. If you do this you don't need ExternalProject, but you do need to do some really dirty hacks. If you want to understand those hacks, just look at CompilerRTDarwinUtils.cmake in compiler-rt. That is a bit of evil that I’m responsible for, and I’ll be paying down that debt for a long time to come.<br class=""></blockquote><br class="">Point taken, it is horrible. (sorry)<br class=""><br class=""><br class=""><blockquote type="cite" class="">Apart from this we also have another problem. The build system makes configuration decisions based on the compiler *at configuration time*. The problem is you really want to configure compiler-rt (and the other runtimes) *after* you've already built clang so the runtimes are configured and built with the clang you just built. The only way to do that is with some mechanism similar to ExternalProject.<br class=""></blockquote><br class=""><devil's advocate>We could come up with a set of rules that makes it<br class="">possible (not preferable) to do so at config time.</da><br class=""><br class="">Is that where the current complication comes from? What makes it so<br class="">horrible and ends up as a home brew version of ExternalProject?<br class=""></div></div></blockquote><div><br class=""></div><div>Recent CMakes have a few interesting things for us in ExternalProject.</div><div><br class=""></div><div>CMake 3.1 added BUILD_ALWAYS (2a93843) which allows the build target of a sub-project to always be called. This is really important because when you use external projects the top-level build file doesn’t have the dependency information for the sub-projects. So if you change sources in compiler-rt it won’t know to rebuild compiler-rt. You need to force it to always invoke ninja in the sub-project so that it will pick up changes.</div><div><br class=""></div><div>Unfortunately even with CMake 3.1 BUILD_ALWAYS doesn’t actually work for Ninja because of a bug that was fixed in CMake 3.4.1 (b6f4717).</div><div><br class=""></div><div>I’m suggesting the version 3.4.3 because it is the last 3.4.x build, and the CMake community is really strict about what gets put into patch releases.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><br class=""><blockquote type="cite" class="">We could roll our own. At this point I'm going to put on my "non-constructive reality" hat. I'm not going to do that.<br class=""></blockquote><br class="">Absolutely not. Ten shots to the head before we start rolling thing<br class="">our own that are perfectly covered by a tool we already use.<br class=""><br class=""><br class=""><blockquote type="cite" class="">Replicating ExternalProject would be a lot of work...<br class=""></blockquote><br class="">Just to be clear, I didn't mean that. If you're saying that, to get<br class="">the desired functionality we'll either need ExternalProject or<br class="">something identical to it, then the choice is clear. I was asking if<br class="">there was another (good, but less good) solution to the problem.<br class=""><br class="">Rolling our own is not even a solution, much less a good one.<br class=""></div></div></blockquote><div><br class=""></div><div>It isn’t necessarily something identical to it. ExternalProject isn’t actually designed for this use, and it has loads of functionality we don’t need.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><br class=""><blockquote type="cite" class="">As a data point, the one place in LLVM where we don't use ExternalProject (and we should be) is the cross-compiling goop, and it is a gigantic mess (see: CrossCompile.cmake and every mention of LLVM_NATIVE_BUILD in TableGen.cmake). It is filled with bugs and in desperate need of disentangling. This is another one of my sins that I need to repent.<br class=""></blockquote><br class="">Oh, so ExternalProject would also fix cross compilation!? I'm sold! :)<br class=""></div></div></blockquote><div><br class=""></div><div>And hopefully we can use it to make the optimized tablegen option more robust too.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><br class=""><blockquote type="cite" class="">I feel I should also point out that ExternalProject isn't a silver bullet. It isn't going to solve all our problems, and since it is one of the more actively changing parts of CMake we may find ourselves re-visiting this conversation in a year or two talking about a newer version of CMake.<br class=""></blockquote><br class="">Right, this is an interesting point. I don't want to do this every<br class="">year, so let's be as reasonable as we can.<br class=""><br class="">Is there anything in 3.5 that can really save us a lot of effort in<br class="">the current work?<br class=""></div></div></blockquote><div><br class=""></div><div>I don’t believe so. I’ve read the release notes (<a href="https://cmake.org/cmake/help/v3.5/release/3.5.html" class="">https://cmake.org/cmake/help/v3.5/release/3.5.html</a>), and I don’t think there is anything really important to us in them. I am interested in a few things being discussed on the cmake-developers list though (<a href="http://public.kitware.com/pipermail/cmake-developers/2016-January/027370.html" class="">http://public.kitware.com/pipermail/cmake-developers/2016-January/027370.html</a>). It looks like that might make CMake 3.6, and it could be interesting for us. That said, this is likely a case where we could easily support the old and new versions without much problem and it doesn’t impact build correctness.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">I'm now using CMake 3.2.2 on all buildbots. If I have to move it up to<br class="">3.4.3, I'm fairly confident that there will be absolutely no problem<br class="">with it.<br class=""><br class="">But as Chuck said, there were some crashes on 3.5.2 that needed 3.5.3,<br class="">and by using it on so many different platforms, we may uncover bugs,<br class="">and may have to roll back to 3.4 temporarily, and then forwards to<br class="">3.5, etc.<br class=""></div></div></blockquote><div><br class=""></div><div>This is a big part of why I’m suggesting 3.4.3 instead of 3.5.0 or 3.5.1 which are also widely available.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">I really want to avoid that. But I also want to avoid doing this over<br class="">again next year.<br class=""></div></div></blockquote><div><br class=""></div><div>While I don’t want to advocate for us updating frequently “just because”, I do think that if there are compelling reasons to update every year or two, we shouldn’t be afraid to.</div><div><br class=""></div><div>-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Finally, Linaro cares more about Linux on ARM (v7+) than bare-metal,<br class="">but we can't just break the rest. I know there are people out there<br class="">that have infrastructure to test that kind of restricted environment,<br class="">not only on ARM, but also MIPS and old PPC32 stuff. I think they<br class="">should voice their concerns before we take any harsh decision.<br class=""><br class="">cheers,<br class="">--renato<br class=""></div></div></blockquote></div><br class=""></body></html>