<div dir="ltr"><div>This is valuable feedback, and I think it would help if you could please post it in on the thread on the benchmark project side (i.e. <a href="https://github.com/google/benchmark/pull/1183">https://github.com/google/benchmark/pull/1183</a>), since it would help the decision making process there - thanks!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 7, 2021 at 7:22 PM Stella Laurenzo <<a href="mailto:stellaraccident@gmail.com">stellaraccident@gmail.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>Perhaps an unpopular opinion, but I don't see the value proposition in foundation things like benchmark taking such convenience dependencies. Abseil is not a lightweight dependency, either from the code or the build system perspective, and it will limit portability (such a thing is hard to prove, but I can speak from experience, being a downstream that has taken the time to scalpel Abseil out in order to achieve better compatibility and footprint).<div dir="auto"><br></div><div dir="auto">In my experience, there are typically a small handful of things that actually boost such a project (usually related to strings and collections). For foundation components, I would far rather see such things forked in if needed vs adding a hard dependency. Even better if components like abseil were unobtrusive in keeping things separated for this form of sharing.</div><div dir="auto"><br></div><div dir="auto">My project will most likely fork benchmark or switch to something lighter if it goes down this path. LLVM can of course take its own path but I generally consider forking when I see foundation components start down the path of losing control of their dependencies.<br><div dir="auto"><br></div><div dir="auto"></div></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 7, 2021, 6:57 PM Matthias Braun via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" 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"><br>
<br>
> On Sep 30, 2021, at 10:07 AM, Mircea Trofin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> TL;DR; When either of LLVM_BUILD_BENCHMARKS or LIBCXX_INCLUDE_BENCHMARKS are enabled, as well as for llvm-test-suite, a dependency to abseil would either be auto-downloaded by the build system, or need to be user-specifiable, or provided in the source tree.<br>
<br>
FWIW: I'm not a fan of auto-downloading stuff. That's just a sneaky to add a dependency that sure may not give trouble to the users where the auto-download succeeds. But many companies have their build farms isolated from the internet and security people would not be happy if we just download a blob of code from a separate project that can change somewhat unnoticed by users of LLVM.<br>
<br>
Can't we copy the thing into the LLVM repository (aka vendoring) like we copied the benchmark library? I feel that things become a different story when we actually add dependencies...<br>
<br>
- Matthias<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div>
</blockquote></div></div>