<div dir="ltr">I'll bite:<div><br></div><div>Do you really believe you could ever get these folks to choose consistent llvm versions anyway?<br><br></div><div>Or will you always have to do the work yourself anyway?</div><div><br></div><div>In my talks with a number of these projects, they pretty much don't care what anyone else does, and plan to stick to their own import/etc schedules no matter what LLVM does with stable releases :)</div><div><br></div><div>(For reference, Google *ships* the equivalent of about 13-16 linux distributions in products, uses about 5-6x that internally, and we have a single monolithic source repository for the most part.  I have the joy of owning the third party software policies/etc for it, and so  end up responsible for trying to deal with maintaining single versions of llvm for tens to hundreds of packages).</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 12, 2016 at 8:27 AM, Bernhard Rosenkränzer <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On 12 May 2016 at 16:56, Kristof Beyls <span dir="ltr"><<a href="mailto:Kristof.Beyls@arm.com" target="_blank">Kristof.Beyls@arm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word"><div>In my opinion, it would be better overall for the LLVM project if top-of-trunk is</div>
<div>tested as much as possible, if testing resources are so scarce that a choice</div>
<div>has to be made between testing top-of-trunk or testing a release branch.</div></div></blockquote><div><br></div></span><div>I agree that trunk is more important, with both of my hats on.</div><div><br></div><div>But releases are not completely irrelevant - one thing making them important is the fact that there's other projects out there using the LLVM libraries - and as a distro, we have to make sure they all work (so they agree on the same API), preferably without having to ship multiple versions of LLVM and preferably without having to patch external code too much to adjust to API changes.</div><div><br></div><div>In OpenMandriva, we have to keep Mesa, creduce, emscripten and the LLVMified Qt moc working (list expected to grow -- ultimately we'd also like to use the system LLVM libraries for the swift compiler).</div><div>In AOSP, RenderScript relies on the LLVM API, but there's nothing else using it, so there's currently no need to force a common version of the API between different projects there.</div><div><br></div><div>ttyl</div><div>bero</div></div></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>