<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 4, 2019 at 9:34 AM Chris Bieneman via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">I'm not sure what benefit that would provide. For most developers they already have configured build directories </div></blockquote><div><br>While I agree adding a bootstrap script is probably not worth the cost - an/the important benefit wouldn't be to existing developers, but to making the barrier of entry lower to encourage new contributors, I think.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">and if their CMake is too old they are going to do a `git pull` and all of a sudden their build fails to configure. Then they go fetch a new CMake. Not sure a bootstrap script really helps with that. Especially since the CMake git repository contains one, and many people might prefer to grab a binary distribution rather than build their own.<div><br></div><div>-Chris<br><div><br><blockquote type="cite"><div>On Nov 4, 2019, at 9:29 AM, Stephen Neuendorffer <<a href="mailto:stephen.neuendorffer@gmail.com" target="_blank">stephen.neuendorffer@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Maybe a bootstrap.sh? I understand that it can get a little tricky, but even if it only worked 95% of the time it might be enough to lower the barrier to entry.<div><br><div>Steve</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 4, 2019 at 9:16 AM Chris Bieneman <<a href="mailto:chris.bieneman@me.com" target="_blank">chris.bieneman@me.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr">CMake doesn’t have the ability to reliably re-invoke itself in a way that would make that workflow reasonable. To do it would require a meta build system for our meta build system, and that is the road to madness.</div><div dir="ltr"><br></div><div dir="ltr">-Chris</div><div dir="ltr"><br><blockquote type="cite">On Nov 4, 2019, at 8:59 AM, Stephen Neuendorffer via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><br><div>Since it's 'so easy', I wonder if it would make people's lives easier to add a bootstrap of cmake to the out of the box build flow.</div><div>Maybe: "You're system Cmake is too old for us. Downloading and building a cmake 1.15.1 locally for you...."</div><div><br></div><div>Steve</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 4, 2019 at 7:20 AM James Y Knight via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Sun, Nov 3, 2019 at 7:20 PM Neil Nelson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><p><font size="-1">Glad we are getting some reasonable
justifications for CMake 3.15.0. There are two points we may be
missing.</font></p><p><font size="-1">Is our plan to just keep updating to the most
recent CMake version or will our objectives be reached with this
version? If we gain what we need with this version then after a
while we will have the Ubuntu LTS aligned.</font></p><p><font size="-1">For my current purposes, LLVM can get wild
without much worry here. I just clone a VM and run what is
useful and then delete it. A bit like use once and throw away.
This is not for production purposes but for getting a better
view of software structure that LLVM can provide.</font></p><p><font size="-1">When I was managing IT and the servers for a
small company that needed to be live 24/7 we used the latest
Ubuntu LTS version because we needed rock-solid performance as
best we could get. The software in the LTS version is tested and
used by a large user base with necessary updates and so we
expected to have high reliability.<br>
</font></p><p><font size="-1">Those saying how easy it was to obtain the latest
CMake have apparently not been faced with the absolute need for
solid up-time. Installing hack-me-now, buggy, bleeding-edge
software was </font><font size="-1"><span>severely</span>
discouraged. But in the LLVM environment, I can see where that
is not a strong necessity.</font></p><p><font size="-1">But at the same time, does LLVM strive to be the
backbone of 24/7 software? Or is it more of a cool thing with
some interesting code analysis properties? I suspect its nature
is a bit wild, bleeding edge. And that's OK.</font></p></div></blockquote><div>I'm not really sure what your worry is here -- if you're downloading and building a development version of LLVM onto this particular production machine, why is it problematic to also download a newer release version of CMake to build it with?</div><div><br></div><div>Maybe you're worried that you'd have to install the new cmake into /usr/local/bin? If that's the worry, I'll note that you are not required to install cmake into /usr/local/bin/ in order to use it to build LLVM, and I'd recommend not doing so. You can actually invoke the cmake binary directly from its build/download directory -- no "make install" required at all. Used that way, it doesn't affect anything else on your system -- if you like, the new cmake can be used ONLY for building LLVM, and affect literally nothing else other than a tiny amount of disk-space.</div><div><br></div><div>Another important point here is that the version of cmake you use to build llvm doesn't impact users of the llvm libraries or binaries that were built with the new cmake. (I'd contrast that with llvm requiring a newer version of a shared library, which _does_ have runtime impact, and thus is of potentially larger concern.)</div><div></div><div> </div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
<span>_______________________________________________</span><br><span>LLVM Developers mailing list</span><br><span><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a></span><br><span><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></span><br></div></blockquote></div></blockquote></div>
</div></blockquote></div><br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>