summaryrefslogtreecommitdiff
path: root/FAQ.md
diff options
context:
space:
mode:
authorGravatar Abseil Team <absl-team@google.com>2020-02-14 09:41:25 -0800
committerGravatar Mark Barolak <mbar@google.com>2020-02-14 12:54:19 -0500
commit3c814105108680997d0821077694f663693b5382 (patch)
treef414158f000b24926b4110dd1c3a640106fe630c /FAQ.md
parentc44657f55692eddf5504156645d1f4ec7b3acabd (diff)
Export of internal Abseil changes
-- 97faa5fdfa4cd5d7a74cd9332cddd8a7c1e67b89 by Abseil Team <absl-team@google.com>: Internal changes PiperOrigin-RevId: 295164378 -- 74990f100b3f4172c770ef8c76c05c8e99febdde by Xiaoyi Zhang <zhangxy@google.com>: Release `absl::Cord`. PiperOrigin-RevId: 295161959 -- 6018c57f43c45c31dc1a61c0cd75fa2aa9be8dab by Gennadiy Rozental <rogeeff@google.com>: Introduce independent notion of FlagStaticTypeID. This change separates static flag value type identification from the type specific "vtable" with all the operations specific to value type. This change allows us to do the following: * We can move most of "vtable" implementation from handle header, which will become public soon, into implementation details of Abseil Flag. * We can combine back marshalling ops and general ops into a single vtable routine. They were split previously to facilitate type identification without requiring marshalling routines to be exposed in header. * We do not need to store two vtable pointers. We can now store only one. The static type id can be deduced on request. Overall we are saving 24 bytes per flag according to size_tester run. PiperOrigin-RevId: 295149687 -- 986b78e9ba571aa85154e70bda4580edd45bb7bf by Abseil Team <absl-team@google.com>: Update internal comments. PiperOrigin-RevId: 295030681 -- 825412b29fd6015027bbc3e5f802706eee0d2837 by Matthew Brown <matthewbr@google.com>: Change str_format_internal::ConversionChar to an enum (from a struct-wrapped enum). PiperOrigin-RevId: 294987462 -- f9f88d91809d2cc33fc129df70fa93e7a2c35c69 by Derek Mauro <dmauro@google.com>: Use more precise wording in the question on live-at-head PiperOrigin-RevId: 294957679 GitOrigin-RevId: 97faa5fdfa4cd5d7a74cd9332cddd8a7c1e67b89 Change-Id: I081e70d148ffac7296d65e2a2f775f643eaf70bf
Diffstat (limited to 'FAQ.md')
-rw-r--r--FAQ.md32
1 files changed, 26 insertions, 6 deletions
diff --git a/FAQ.md b/FAQ.md
index af721307..78028fc0 100644
--- a/FAQ.md
+++ b/FAQ.md
@@ -33,8 +33,9 @@ instructions](https://github.com/abseil/abseil-cpp/blob/master/CMake/README.md)
for more information.
For a longer answer to this question and to understand why some other approaches
-don't work, see the answer to "What is ABI and why don't you recommend using a
-pre-compiled version of Abseil?"
+don't work, see the answer to ["What is ABI and why don't you recommend using a
+pre-compiled version of
+Abseil?"](#what-is-abi-and-why-dont-you-recommend-using-a-pre-compiled-version-of-abseil)
## What is ABI and why don't you recommend using a pre-compiled version of Abseil?
@@ -117,7 +118,8 @@ to make it compatible. In practice, the need to use an automated tool is
extremely rare. This means that upgrading from one source release to another
should be a routine practice that can and should be performed often.
-We recommend you update to the latest release of Abseil as often as
+We recommend you update to the [latest commit in the `master` branch of
+Abseil](https://github.com/abseil/abseil-cpp/commits/master) as often as
possible. Not only will you pick up bug fixes more quickly, but if you have good
automated testing, you will catch and be able to fix any [Hyrum's
Law](https://www.hyrumslaw.com/) dependency problems on an incremental basis
@@ -130,9 +132,27 @@ feature, updating the
[`http_archive`](https://docs.bazel.build/versions/master/repo/http.html#http_archive)
rule in your
[`WORKSPACE`](https://docs.bazel.build/versions/master/be/workspace.html) for
-`com_google_abseil` to point to the latest release is all you need to do. You
-can commit the updated `WORKSPACE` file to your source control every time you
-update, and if you have good automated testing, you might even consider
+`com_google_abseil` to point to the [latest commit in the `master` branch of
+Abseil](https://github.com/abseil/abseil-cpp/commits/master) is all you need to
+do. For example, on February 11, 2020, the latest commit to the master branch
+was `98eb410c93ad059f9bba1bf43f5bb916fc92a5ea`. To update to this commit, you
+would add the following snippet to your `WORKSPACE` file:
+
+```
+http_archive(
+ name = "com_google_absl",
+ urls = ["https://github.com/abseil/abseil-cpp/archive/98eb410c93ad059f9bba1bf43f5bb916fc92a5ea.zip"], # 2020-02-11T18:50:53Z
+ strip_prefix = "abseil-cpp-98eb410c93ad059f9bba1bf43f5bb916fc92a5ea",
+ sha256 = "aabf6c57e3834f8dc3873a927f37eaf69975d4b28117fc7427dfb1c661542a87",
+)
+```
+
+To get the `sha256` of this URL, run `curl -sL --output -
+https://github.com/abseil/abseil-cpp/archive/98eb410c93ad059f9bba1bf43f5bb916fc92a5ea.zip
+| sha256sum -`.
+
+You can commit the updated `WORKSPACE` file to your source control every time
+you update, and if you have good automated testing, you might even consider
automating this.
One thing we don't recommend is using GitHub's `master.zip` files (for example