On Tuesday, February 18, 2020, at 9:01 PM +0100, László Böszörményi (GCS) wrote: > There's a compatibility page[1] what Abseil is and isn't. It states > the following things. > "We do not promise any ABI compatibility — we intend for Abseil to be > built from source, hopefully from head. The internal layout of our > types may change at any point, without notice." > As I read waiting for LTS releases might be late (its head commit > version advised to be used). I guess other Google applications other > libraries commonly wants newer Abseil releases than LTS ones.
I think that’s accurate. The culture at Google emphasizes continuous integration from head rather than coding against releases. However, this isn’t just about Google applications. There are other F/OSS projects that want to take an Abseil dependency and aren’t ready to commit to that sort of development model – see, for instance, https://github.com/darktable-org/rawspeed/issues/122 (“Stop reinventing the wheel”), in which Darktable investigates taking an Abseil dependency and decides to wait until the LTS story is fully hammered out. The Abseil team understands that the F/OSS world expects stable ABIs; they’re going to break ABI all over the place at head, but they’re not going to go out of their way to break it within an LTS release. > "Not all Abseil libraries are suitable for dynamic loading. Some > libraries have startup/initialization requirements and may not be > suitable for dynamic loading. We will try to be clear about which > libraries are OK for dynamic loading. However we don’t generally > deploy code in this fashion, mistakes are possible, [...]". > That is, even shared libraries can be built, those are not guaranteed to work. I don’t think we should shy away from providing functionality just because upstream doesn’t guarantee it to work. It’s true that the Abseil developers don’t test Abseil as .so’s, but testing exists in Debian for a reason. If Debian ships an Abseil .so, and bugs appear in testing, we can work with upstream to fix them or patch them ourselves if upstream is nonresponsive. I did discuss the initialization issues with an Abseiler today; he doesn’t know the full story, but he knows somebody within Abseil is working on making initialization more lazy (and therefore more .so-compatible). If you’re interested, I can discuss that with them at our next meeting and let you know what the story is. > I think there should be a compatibility matrix or test if the latest > LTS release is enough for most Google applications or those need newer > versions (no new API added for recent application development). Agreed – there should definitely be some testing involved. For what it’s worth, the next LTS is likely to be cut from head before the end of the week. For a little while afterward, at least, nobody should need anything newer than what’s in the LTS. On Sunday, February 16, 2020, at 10:48 PM +0100, László Böszörményi (GCS) wrote: >>> @Benjamin: may you ask its developers to use the system gtest libraries >>> if only ABSL_RUN_TESTS set to ON? On Monday, February 17, 2020, at 8:21 PM -0500, Benjamin Barenblat wrote: >> Absolutely. I’ll bring it up with them at work tomorrow (today was a US >> holiday). I spoke with an Abseiler today about this. He believes that Abseil definitely needs to support that, but there’s still some consensus-building that needs to happen within the team before we can guarantee that upstream will take a patch for it. I have a preliminary version of such a patch, and I’ll try to get it finished and sent in the next day or two; that way, even if upstream lags taking it, we can import it and get the support we need.