ARROW-15388: [C++] Avoid including absl from flatbuffers

[pitrou]

There may be an incomplete/broken copy of the Abseil library lying around
(for example because of a race condition while installing it as a bundled library).

Since absl is only used by Flatbuffers to provide a string_view facility,
use our own vendored string_view instead.

[pitrou]

@coryan Not sure whether you have an opinion on this?

[github-actions]

https://issues.apache.org/jira/browse/ARROW-15388

[github-actions]

⚠️ Ticket has not been started in JIRA, please click 'Start Progress'.

[coryan]

Not sure whether you have an opinion on this?

To me, it seems odd to patch the code to fix a race condition during the build. Seems like the "Right Thing"[tm] would be to fix the dependency graph to make flatbuffers depend on Abseil? Is that very hard for some reason?

[pitrou]

It's a bit convoluted and awkward, as Abseil is only an optional indirect dependency of the GCSFS implementation. Furthermore, since Flatbuffers is vendored, I don't think it has an existence in the dependency graph at all currently (it's basically always there).

[coryan]

It's a bit convoluted and awkward, as Abseil is only an optional indirect dependency of the GCSFS implementation. Furthermore, since Flatbuffers is vendored, I don't think it has an existence in the dependency graph at all currently (it's basically always there).

I see.

Consider that (by default) absl::string_view is just an alias for std::string_view when compiling with C++ >= 17, and it is a template class when compiling with C++ <= 14 (something I do not happen to like but it is a thing: abseil/abseil-cpp#696). I am not sure if Flatbuffers depends on that (my guess would be no), hopefully not. If it did, you may run intro trouble as it tries to use std::string_view in C++17 but the Arrow version of string_view does not magically convert to std::string_view.

You may want to just disable the automatic detection of Abseil's string view. Just my $0.02, I think your change should work as-is too.

[pitrou]

Flatbuffers' use of string_view is merely to enable two APIs (that we don't currently use AFAICT, so we may indeed as well disable it). It doesn't store any std::string_view under the hood, so that should be fine.

[lidavidm]

If it just enables APIs we don't use, I would lean towards avoiding the mess in the first place and just removing the detection as well. But as-is things are OK here too.

[kszucs]

@pitrou shall we include this in 7.0 (in the case I need to cut another RC)?

[pitrou]

@kszucs There's no real need to.

[pitrou]

Crossbow C++ builds: https://github.com/ursacomputing/crossbow/branches/all?page=1&query=build-592

[ursabot]

Benchmark runs are scheduled for baseline = a3efe72 and contender = 22dc537. 22dc537 is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Finished ⬇️0.0% ⬆️0.0%] ec2-t3-xlarge-us-east-2
[Failed ⬇️0.91% ⬆️0.0%] ursa-i9-9960x
[Finished ⬇️0.3% ⬆️0.04%] ursa-thinkcentre-m75q
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python. Runs only benchmarks with cloud = True
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java