blob: 230bf1eecc4a4b35c9beddaa69332d83d2a68911 [file] [log] [blame]
Austin Schuhb4691e92020-12-31 12:37:18 -08001// 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_