brintos

brintos / llvm-project-archived public Read only

0
0
Text · 2.6 KiB · 402f4c7 Raw
69 lines · plain
1==================================================2Capturing configuration information in the headers3==================================================4 5.. contents::6   :local:7 8The Problem9===========10 11libc++ supports building the library with a number of different configuration options.12In order to support persistent configurations and reduce arbitrary preprocessor logic13in the headers, libc++ has a mechanism to capture configuration options in the14installed headers so they can be used in the rest of the code.15 16 17Design Goals18============19 20* The solution should be simple, consistent and robust to avoid subtle bugs.21 22* Developers should test the code the same way it will be deployed -- in other words,23  the headers used to run tests should be the same that we install in order24  to avoid bugs creeping up.25 26* It should allow different targets or flavors of the library to use a different27  configuration without having to duplicate all the libc++ headers.28 29 30The Solution31============32 33When you first configure libc++ using CMake, a ``__config_site`` file is generated34to capture the various configuration options you selected. The ``__config`` header35used by all other headers includes this ``__config_site`` header first in order to36get the correct configuration.37 38The ``__config_site`` header is hence the only place where persistent configuration39is stored in the library. That header essentially reflects how the vendor configured40the library. As we evolve the library, we can lift configuration options into that41header in order to reduce arbitrary hardcoded choices elsewhere in the code. For42example, instead of assuming that a specific platform doesn't provide some functionality,43we can create a generic macro to guard it and vendors can define the macro when44configuring the library on that platform. This makes the "carve off" reusable in45other circumstances instead of tying it tightly to a single platform.46 47Furthermore, the Clang driver now looks for headers in a target-specific directory48for libc++. By installing the ``__config_site`` header (and only that header) to49this target-specific directory, it is possible to share the libc++ headers for50multiple targets, and only duplicate the persistent information located in the51``__config_site`` header. For example:52 53.. code-block:: bash54 55  include/c++/v1/56    vector57    map58    etc...59 60  include/<targetA>/c++/v1/61    __config_site62 63  include/<targetB>/c++/v1/64    __config_site65 66When compiling for ``targetA``, Clang will use the ``__config_site`` inside67``include/<targetA>/c++/v1/``, and the corresponding ``__config_site`` for68``targetB``.69