Does the amalgamation have to be regenerated per platform/compiler?

[ethindp]

So, I'm not certain if I missed this in the docs or not, but given that the amalgamation generates files I can just drop into my own source code, do I have to regenerate it for each platform and compiler combination I wish to use? I ask because, for MSVC, for example, configure.py says warnings like:

   INFO: Skipping (dependency failure): gost_3411 noekeon_simd
   INFO: Skipping (deprecated): dilithium_aes dlies gost_28147 gost_3410 kyber_90s lion mce md4 noekeon prf_x942 shake_cipher streebog tpm
   INFO: Skipping (incompatible CPU): aes_armv8 aes_power8 sha1_armv8 sha2_32_armv8 sha2_64_armv8 shacal2_armv8 sm4_armv8
   INFO: Skipping (incompatible OS): certstor_system_macos commoncrypto fd_unix getentropy
   INFO: Skipping (incompatible compiler): argon2_ssse3 keccak_perm_bmi2 serpent_avx2 serpent_avx512 sha2_32_bmi2 sha2_64_bmi2

Is there a way I can make a "universal" amalgamation I can just drop into my own projects? Or is it better to generate the amalgamation for each configuration? (The skipping of deprecated features was something I explicitly used, but the rest wasn't.)

[reneme]

Perhaps that documentation chapter answers your question: https://botan.randombit.net/handbook/building.html#amalgamation

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.

[ethindp]

Huh, okay, so I should probably generate one at configure time to get all the performance advantages. Can do! :) Thanks!