diff options
author | Jack Lloyd <[email protected]> | 2020-01-22 08:36:45 -0500 |
---|---|---|
committer | Jack Lloyd <[email protected]> | 2020-01-22 09:18:54 -0500 |
commit | 8afc681704950df8f6cae99408b53d9fc536f7e7 (patch) | |
tree | 13cb8f0ec9d2053a1f654cc49f2b5240b2636538 /doc | |
parent | 206c18114e7e7336a6f41251979b979bb74223e7 (diff) |
Remove support for splitting the amalgamation by ABI
This is as if --single-file-amalgamation was always used, except
also now botan_all_internal.h is not created.
This effectively drops support for very old GCC/Clang in the
amalgamation (only). GCC 5+ and Clang 3.8+ support the target
attribute and work fine. MSVC not affected since it doesn't need
such attributes in the first place.
Diffstat (limited to 'doc')
-rw-r--r-- | doc/building.rst | 62 |
1 files changed, 26 insertions, 36 deletions
diff --git a/doc/building.rst b/doc/building.rst index fa2d1b40f..4d906f59b 100644 --- a/doc/building.rst +++ b/doc/building.rst @@ -306,34 +306,34 @@ The Amalgamation Build You can also configure Botan to be built using only a single source file; this is quite convenient if you plan to embed the library into another application. -To generate the amalgamation, run ``configure.py`` with whatever -options you would ordinarily use, along with the option -``--amalgamation``. This will create two (rather large) files, -``botan_all.h`` and ``botan_all.cpp``, plus (unless the option -``--single-amalgamation-file`` is used) also some number of files like -``botan_all_aesni.cpp`` and ``botan_all_sse2.cpp`` which need to be -compiled with the appropriate compiler flags to enable that -instruction set. The ISA specific files are only generated if there is -code that requires them, so you can simplify your build. The -``--minimized-build`` option (described elsewhere in this documentation) -is also quite useful with the amalgamation. +To generate the amalgamation, run ``configure.py`` with whatever options you +would ordinarily use, along with the option ``--amalgamation``. This will create +two (rather large) files, ``botan_all.h`` and ``botan_all.cpp``. + +.. note:: + + The library will as usual be configured to target some specific operating + system and CPU architecture. You can use the CPU target "generic" if you need + to target multiple CPU architectures, but this has the effect of disabling + *all* CPU specific features such as SIMD, AES instruction sets, or inline + assembly. If you need to ship amalgamations for multiple targets, it would be + better to create different amalgamation files for each individual target. Whenever you would have included a botan header, you can then include -``botan_all.h``, and include ``botan_all.cpp`` along with the rest of -the source files in your build. If you want to be able to easily -switch between amalgamated and non-amalgamated versions (for instance -to take advantage of prepackaged versions of botan on operating -systems that support it), you can instead ignore ``botan_all.h`` and -use the headers from ``build/include`` as normal. - -You can also build the library using Botan's build system (as normal) -but utilizing the amalgamation instead of the individual source files -by running something like ``./configure.py --amalgamation && make``. -This is essentially a very simple form of link time optimization; -because the entire library source is visible to the compiler, it has -more opportunities for interprocedural optimizations. -Additionally, amalgamation builds usually have significantly shorter -compile times for full rebuilds. +``botan_all.h``, and include ``botan_all.cpp`` along with the rest of the source +files in your build. If you want to be able to easily switch between amalgamated +and non-amalgamated versions (for instance to take advantage of prepackaged +versions of botan on operating systems that support it), you can instead ignore +``botan_all.h`` and use the headers from ``build/include`` as normal. + +You can also build the library using Botan's build system (as normal) but +utilizing the amalgamation instead of the individual source files by running +something like ``./configure.py --amalgamation && make``. This is essentially a +very simple form of link time optimization; because the entire library source is +visible to the compiler, it has more opportunities for interprocedural +optimizations. Additionally (assuming you are not making use of a compiler +cache such as ``ccache`` or ``sccache``) amalgamation builds usually have +significantly shorter compile times for full rebuilds. Modules Relying on Third Party Libraries ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -753,16 +753,6 @@ Enable debug info and disable optimizations Use amalgamation to build -``--single-amalgamation-file`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -By default the amalgamation file is split up into several files, -because using intrinsics requires enabling the relevant instruction -set extension. This option selects generating a single file instead. - -This requires either MSVC, or a fairly recent version of GCC/Clang -which supports the ``target`` attribute. - ``--system-cert-bundle`` ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |