<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 28, 2015 at 5:02 PM, Devin Coughlin <span dir="ltr"><<a href="mailto:dcoughlin@apple.com" target="_blank">dcoughlin@apple.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"><span class="">On Sep 28, 2015, at 4:33 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br></span><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Sep 28, 2015 at 4:25 PM, Devin Coughlin via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br></span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
We propose taking a “curl + cache” approach to benchmarks. That is, we won’t store the benchmarks themselves in a repository. Instead, the bots will download them from the projects' websites and cache locally.</blockquote><div><br></div></span><div>If we're going to be downloading things from external sources, those sources could be changing, no? Or will we pin to a specific version.</div></div></div></div></div></blockquote><div><br></div><div>We will pin it to a specific version, although we may want to periodically (yearly or even less frequently) update to a newer version of the benchmarks to make sure we get good coverage of newer language features and to keep the benchmarks compiling with ToT clang.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>if we're pinning to a specific version, what's the benefit to taking an external dependency like that (untrusted, may be down when we need it, etc), compared to copying the files permanently & checking them in to clang-tests (or clang-tests-external) as I did for GDB?<br></div></div></div></div></div></blockquote><div><br></div></span><div>The goal here is to avoid unnecessary co-mingling of benchmarks with different licenses in the <a href="http://llvm.org" target="_blank">llvm.org</a> repositories — but as you point out, it comes with significant downsides. What has your experience with gdb and clang-test-external been like? Has dealing with differing licensing w/r/t clang been a challenge?</div></div></div></blockquote><div><br></div><div>I don't believe so - we just put it out in a separate repository from clang-tests, to ensure those who might have reasons for not wanting to view code under such a license could ensure they didn't accidentally run across it.<br><br>But as usual, legal/licensing issues should be directed at lawyers, of which I am not one.<br><br>- David</div></div><br></div></div>