Austin Schuh | b4691e9 | 2020-12-31 12:37:18 -0800 | [diff] [blame^] | 1 | // Copyright 2019 The Abseil Authors. |
| 2 | // |
| 3 | // Licensed under the Apache License, Version 2.0 (the "License"); |
| 4 | // you may not use this file except in compliance with the License. |
| 5 | // You may obtain a copy of the License at |
| 6 | // |
| 7 | // https://www.apache.org/licenses/LICENSE-2.0 |
| 8 | // |
| 9 | // Unless required by applicable law or agreed to in writing, software |
| 10 | // distributed under the License is distributed on an "AS IS" BASIS, |
| 11 | // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 12 | // See the License for the specific language governing permissions and |
| 13 | // limitations under the License. |
| 14 | // |
| 15 | // ----------------------------------------------------------------------------- |
| 16 | // File: options.h |
| 17 | // ----------------------------------------------------------------------------- |
| 18 | // |
| 19 | // This file contains Abseil configuration options for setting specific |
| 20 | // implementations instead of letting Abseil determine which implementation to |
| 21 | // use at compile-time. Setting these options may be useful for package or build |
| 22 | // managers who wish to guarantee ABI stability within binary builds (which are |
| 23 | // otherwise difficult to enforce). |
| 24 | // |
| 25 | // *** IMPORTANT NOTICE FOR PACKAGE MANAGERS: It is important that |
| 26 | // maintainers of package managers who wish to package Abseil read and |
| 27 | // understand this file! *** |
| 28 | // |
| 29 | // Abseil contains a number of possible configuration endpoints, based on |
| 30 | // parameters such as the detected platform, language version, or command-line |
| 31 | // flags used to invoke the underlying binary. As is the case with all |
| 32 | // libraries, binaries which contain Abseil code must ensure that separate |
| 33 | // packages use the same compiled copy of Abseil to avoid a diamond dependency |
| 34 | // problem, which can occur if two packages built with different Abseil |
| 35 | // configuration settings are linked together. Diamond dependency problems in |
| 36 | // C++ may manifest as violations to the One Definition Rule (ODR) (resulting in |
| 37 | // linker errors), or undefined behavior (resulting in crashes). |
| 38 | // |
| 39 | // Diamond dependency problems can be avoided if all packages utilize the same |
| 40 | // exact version of Abseil. Building from source code with the same compilation |
| 41 | // parameters is the easiest way to avoid such dependency problems. However, for |
| 42 | // package managers who cannot control such compilation parameters, we are |
| 43 | // providing the file to allow you to inject ABI (Application Binary Interface) |
| 44 | // stability across builds. Settings options in this file will neither change |
| 45 | // API nor ABI, providing a stable copy of Abseil between packages. |
| 46 | // |
| 47 | // Care must be taken to keep options within these configurations isolated |
| 48 | // from any other dynamic settings, such as command-line flags which could alter |
| 49 | // these options. This file is provided specifically to help build and package |
| 50 | // managers provide a stable copy of Abseil within their libraries and binaries; |
| 51 | // other developers should not have need to alter the contents of this file. |
| 52 | // |
| 53 | // ----------------------------------------------------------------------------- |
| 54 | // Usage |
| 55 | // ----------------------------------------------------------------------------- |
| 56 | // |
| 57 | // For any particular package release, set the appropriate definitions within |
| 58 | // this file to whatever value makes the most sense for your package(s). Note |
| 59 | // that, by default, most of these options, at the moment, affect the |
| 60 | // implementation of types; future options may affect other implementation |
| 61 | // details. |
| 62 | // |
| 63 | // NOTE: the defaults within this file all assume that Abseil can select the |
| 64 | // proper Abseil implementation at compile-time, which will not be sufficient |
| 65 | // to guarantee ABI stability to package managers. |
| 66 | |
| 67 | #ifndef ABSL_BASE_OPTIONS_H_ |
| 68 | #define ABSL_BASE_OPTIONS_H_ |
| 69 | |
| 70 | // Include a standard library header to allow configuration based on the |
| 71 | // standard library in use. |
| 72 | #ifdef __cplusplus |
| 73 | #include <ciso646> |
| 74 | #endif |
| 75 | |
| 76 | // ----------------------------------------------------------------------------- |
| 77 | // Type Compatibility Options |
| 78 | // ----------------------------------------------------------------------------- |
| 79 | // |
| 80 | // ABSL_OPTION_USE_STD_ANY |
| 81 | // |
| 82 | // This option controls whether absl::any is implemented as an alias to |
| 83 | // std::any, or as an independent implementation. |
| 84 | // |
| 85 | // A value of 0 means to use Abseil's implementation. This requires only C++11 |
| 86 | // support, and is expected to work on every toolchain we support. |
| 87 | // |
| 88 | // A value of 1 means to use an alias to std::any. This requires that all code |
| 89 | // using Abseil is built in C++17 mode or later. |
| 90 | // |
| 91 | // A value of 2 means to detect the C++ version being used to compile Abseil, |
| 92 | // and use an alias only if a working std::any is available. This option is |
| 93 | // useful when you are building your entire program, including all of its |
| 94 | // dependencies, from source. It should not be used otherwise -- for example, |
| 95 | // if you are distributing Abseil in a binary package manager -- since in |
| 96 | // mode 2, absl::any will name a different type, with a different mangled name |
| 97 | // and binary layout, depending on the compiler flags passed by the end user. |
| 98 | // For more info, see https://abseil.io/about/design/dropin-types. |
| 99 | // |
| 100 | // User code should not inspect this macro. To check in the preprocessor if |
| 101 | // absl::any is a typedef of std::any, use the feature macro ABSL_USES_STD_ANY. |
| 102 | |
| 103 | #define ABSL_OPTION_USE_STD_ANY 2 |
| 104 | |
| 105 | |
| 106 | // ABSL_OPTION_USE_STD_OPTIONAL |
| 107 | // |
| 108 | // This option controls whether absl::optional is implemented as an alias to |
| 109 | // std::optional, or as an independent implementation. |
| 110 | // |
| 111 | // A value of 0 means to use Abseil's implementation. This requires only C++11 |
| 112 | // support, and is expected to work on every toolchain we support. |
| 113 | // |
| 114 | // A value of 1 means to use an alias to std::optional. This requires that all |
| 115 | // code using Abseil is built in C++17 mode or later. |
| 116 | // |
| 117 | // A value of 2 means to detect the C++ version being used to compile Abseil, |
| 118 | // and use an alias only if a working std::optional is available. This option |
| 119 | // is useful when you are building your program from source. It should not be |
| 120 | // used otherwise -- for example, if you are distributing Abseil in a binary |
| 121 | // package manager -- since in mode 2, absl::optional will name a different |
| 122 | // type, with a different mangled name and binary layout, depending on the |
| 123 | // compiler flags passed by the end user. For more info, see |
| 124 | // https://abseil.io/about/design/dropin-types. |
| 125 | |
| 126 | // User code should not inspect this macro. To check in the preprocessor if |
| 127 | // absl::optional is a typedef of std::optional, use the feature macro |
| 128 | // ABSL_USES_STD_OPTIONAL. |
| 129 | |
| 130 | #define ABSL_OPTION_USE_STD_OPTIONAL 2 |
| 131 | |
| 132 | |
| 133 | // ABSL_OPTION_USE_STD_STRING_VIEW |
| 134 | // |
| 135 | // This option controls whether absl::string_view is implemented as an alias to |
| 136 | // std::string_view, or as an independent implementation. |
| 137 | // |
| 138 | // A value of 0 means to use Abseil's implementation. This requires only C++11 |
| 139 | // support, and is expected to work on every toolchain we support. |
| 140 | // |
| 141 | // A value of 1 means to use an alias to std::string_view. This requires that |
| 142 | // all code using Abseil is built in C++17 mode or later. |
| 143 | // |
| 144 | // A value of 2 means to detect the C++ version being used to compile Abseil, |
| 145 | // and use an alias only if a working std::string_view is available. This |
| 146 | // option is useful when you are building your program from source. It should |
| 147 | // not be used otherwise -- for example, if you are distributing Abseil in a |
| 148 | // binary package manager -- since in mode 2, absl::string_view will name a |
| 149 | // different type, with a different mangled name and binary layout, depending on |
| 150 | // the compiler flags passed by the end user. For more info, see |
| 151 | // https://abseil.io/about/design/dropin-types. |
| 152 | // |
| 153 | // User code should not inspect this macro. To check in the preprocessor if |
| 154 | // absl::string_view is a typedef of std::string_view, use the feature macro |
| 155 | // ABSL_USES_STD_STRING_VIEW. |
| 156 | |
| 157 | #define ABSL_OPTION_USE_STD_STRING_VIEW 2 |
| 158 | |
| 159 | // ABSL_OPTION_USE_STD_VARIANT |
| 160 | // |
| 161 | // This option controls whether absl::variant is implemented as an alias to |
| 162 | // std::variant, or as an independent implementation. |
| 163 | // |
| 164 | // A value of 0 means to use Abseil's implementation. This requires only C++11 |
| 165 | // support, and is expected to work on every toolchain we support. |
| 166 | // |
| 167 | // A value of 1 means to use an alias to std::variant. This requires that all |
| 168 | // code using Abseil is built in C++17 mode or later. |
| 169 | // |
| 170 | // A value of 2 means to detect the C++ version being used to compile Abseil, |
| 171 | // and use an alias only if a working std::variant is available. This option |
| 172 | // is useful when you are building your program from source. It should not be |
| 173 | // used otherwise -- for example, if you are distributing Abseil in a binary |
| 174 | // package manager -- since in mode 2, absl::variant will name a different |
| 175 | // type, with a different mangled name and binary layout, depending on the |
| 176 | // compiler flags passed by the end user. For more info, see |
| 177 | // https://abseil.io/about/design/dropin-types. |
| 178 | // |
| 179 | // User code should not inspect this macro. To check in the preprocessor if |
| 180 | // absl::variant is a typedef of std::variant, use the feature macro |
| 181 | // ABSL_USES_STD_VARIANT. |
| 182 | |
| 183 | #define ABSL_OPTION_USE_STD_VARIANT 2 |
| 184 | |
| 185 | |
| 186 | // ABSL_OPTION_USE_INLINE_NAMESPACE |
| 187 | // ABSL_OPTION_INLINE_NAMESPACE_NAME |
| 188 | // |
| 189 | // These options controls whether all entities in the absl namespace are |
| 190 | // contained within an inner inline namespace. This does not affect the |
| 191 | // user-visible API of Abseil, but it changes the mangled names of all symbols. |
| 192 | // |
| 193 | // This can be useful as a version tag if you are distributing Abseil in |
| 194 | // precompiled form. This will prevent a binary library build of Abseil with |
| 195 | // one inline namespace being used with headers configured with a different |
| 196 | // inline namespace name. Binary packagers are reminded that Abseil does not |
| 197 | // guarantee any ABI stability in Abseil, so any update of Abseil or |
| 198 | // configuration change in such a binary package should be combined with a |
| 199 | // new, unique value for the inline namespace name. |
| 200 | // |
| 201 | // A value of 0 means not to use inline namespaces. |
| 202 | // |
| 203 | // A value of 1 means to use an inline namespace with the given name inside |
| 204 | // namespace absl. If this is set, ABSL_OPTION_INLINE_NAMESPACE_NAME must also |
| 205 | // be changed to a new, unique identifier name. In particular "head" is not |
| 206 | // allowed. |
| 207 | |
| 208 | #define ABSL_OPTION_USE_INLINE_NAMESPACE 0 |
| 209 | #define ABSL_OPTION_INLINE_NAMESPACE_NAME head |
| 210 | |
| 211 | // ABSL_OPTION_HARDENED |
| 212 | // |
| 213 | // This option enables a "hardened" build in release mode (in this context, |
| 214 | // release mode is defined as a build where the `NDEBUG` macro is defined). |
| 215 | // |
| 216 | // A value of 0 means that "hardened" mode is not enabled. |
| 217 | // |
| 218 | // A value of 1 means that "hardened" mode is enabled. |
| 219 | // |
| 220 | // Hardened builds have additional security checks enabled when `NDEBUG` is |
| 221 | // defined. Defining `NDEBUG` is normally used to turn `assert()` macro into a |
| 222 | // no-op, as well as disabling other bespoke program consistency checks. By |
| 223 | // defining ABSL_OPTION_HARDENED to 1, a select set of checks remain enabled in |
| 224 | // release mode. These checks guard against programming errors that may lead to |
| 225 | // security vulnerabilities. In release mode, when one of these programming |
| 226 | // errors is encountered, the program will immediately abort, possibly without |
| 227 | // any attempt at logging. |
| 228 | // |
| 229 | // The checks enabled by this option are not free; they do incur runtime cost. |
| 230 | // |
| 231 | // The checks enabled by this option are always active when `NDEBUG` is not |
| 232 | // defined, even in the case when ABSL_OPTION_HARDENED is defined to 0. The |
| 233 | // checks enabled by this option may abort the program in a different way and |
| 234 | // log additional information when `NDEBUG` is not defined. |
| 235 | |
| 236 | #define ABSL_OPTION_HARDENED 0 |
| 237 | |
| 238 | #endif // ABSL_BASE_OPTIONS_H_ |