[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#888705: abseil-cpp packaging



On Tuesday, May 19, 2020, at  8:59 PM +0200, László Böszörményi (GCS) wrote:
> Doesn't build with GCC 10 due to symbol changes.

Good point. Is there an established way to deal with this? Or should I
just upload this as-is to unstable and then upload a GCC-10-compatible
version to experimental?

> How do you plan Git tagging? Might be better to prefix current tags with
> 'upstream/' and have Debian releases under 'debian/'.

I generally try to keep upstream’s tags intact so that no signatures get
broken. Abseil doesn’t currently sign tags, but they might in the
future, and I’d be a bit bummed if we couldn’t benefit from that. I
think it’s totally reasonable to put Debian releases under debian/, so
if you prefer that approach, I’ll make sure to prefix my tags.

> Rules-Requires-Root might be set to 'no' I guess, but that's nitpicking.

Today I learned about Rules-Requires-Root! I’ve fixed that and pushed
the change.

On Wednesday, May 20, 2020, at 12:03 PM +0200, László Böszörményi (GCS) wrote:
> Please do build static libraries with the following patch.

This is great – thanks! I’m still unfamiliar with CMake; I really
appreciate you figuring out the incantations to get it to build both.

As written, this patch builds shared libraries first and then archives,
which causes abslTargets.cmake to prefer archives over shared objects
when linking against Abseil. I’d like to modify it to go in the other
order, thus preferring shared libraries over archives. Requiring an
explicit opt-in before using Abseil archives would make it more
difficult to accidentally violate the One Definition Rule by
accidentally double-linking an Abseil archive. Furthermore, it would
create less work for packagers trying to use the shared Abseil
libraries, which I expect will be the usual case inside Debian. Does
that sound reasonable?


Reply to: