<div dir="auto">Let me parse that thread and see if I have something to offer. I am well aware of the internal Google forces referenced and at play in causing these kinds of changes -- and they are pretty ingrained in the way that Google builds its software. And I suspect that pushing against them is likely not productive. I just think that OSS communities need to think carefully about the hidden costs of riding such coattails.<div dir="auto"><br></div><div dir="auto">Again, in the difficult to prove category -- I used to be an abseil proponent and may still be for software at certain levels of the value chain. But as a low level component targeting weird configurations, our life got substantially better when we ditched it, and it was not cheap to do so, since the conveniences it provides tend to wend their way through from a style perspective. I would summarize the issues as it being very apparent that Abseil has a small compatibility footprint that the maintainers are paying attention to, there is little control/care (that I could find) on internal sprawl or footprint, and it felt like we were always fighting a militant build system that was always unhappy about something. Some of this feedback was given but incentives were clearly not aligned (which is fine -- there were no hard feelings, just pragmatism) and we didn't judge that there would be. So we disconnected ourselves.</div><div dir="auto"><br></div><div dir="auto">I don't know what the right answer is for LLVM -- this may be innocent enough (or at least scoped enough that we can back out and take a different tack if it causes issues). I'm just cautious of such things, having been burned before.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 7, 2021, 7:33 PM Mircea Trofin <<a href="mailto:mtrofin@google.com">mtrofin@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">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 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 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 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 noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div>
</blockquote></div></div>
</blockquote></div>