[llvm-dev] Proposal: introduce dependency on abseil when building benchmarks

[Stella Laurenzo via llvm-dev]

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.

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.

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.

On Thu, Oct 7, 2021, 7:33 PM Mircea Trofin <mtrofin at google.com> wrote:

> 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.
> https://github.com/google/benchmark/pull/1183), since it would help the
> decision making process there - thanks!
>
> On Thu, Oct 7, 2021 at 7:22 PM Stella Laurenzo <stellaraccident at gmail.com>
> wrote:
>
>> 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).
>>
>> 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.
>>
>> 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.
>>
>>
>>
>> On Thu, Oct 7, 2021, 6:57 PM Matthias Braun via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>>
>>>
>>> > On Sep 30, 2021, at 10:07 AM, Mircea Trofin via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>> >
>>> > 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.
>>>
>>> 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.
>>>
>>> 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...
>>>
>>> - Matthias
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211007/0a0af14f/attachment.html>