aboutsummaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
authorJack Lloyd <[email protected]>2020-01-22 08:36:45 -0500
committerJack Lloyd <[email protected]>2020-01-22 09:18:54 -0500
commit8afc681704950df8f6cae99408b53d9fc536f7e7 (patch)
tree13cb8f0ec9d2053a1f654cc49f2b5240b2636538 /doc
parent206c18114e7e7336a6f41251979b979bb74223e7 (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.rst62
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``
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^