One thing I’d like to be a little explicit about - we’re committed to “Improved installation support”, and not any particular solution, so we’re definitely factoring this feedback into our approach - the end goal was always “we’d like for usage to be as easy as adding botan to your dependencies.”
With installation being such a hot topic, there are many differing needs, priorities, and opinions, so any proposed solution is to find out what needs, if any, it does or does not fill, and how to include it in the set of solutions - since solutions are not necessarily mutually exclusive, especially if we have things fall back appropriately.
This topic is worth a doing a writeup of its own in the future, eg “Practical security considerations for binding to C libraries” or something - it’d be great to have something to reference the next time we need to bind to a C library 
@hasufell @jackdk
One thing to note, is that if botan is not system-installed, then running the botan configure script may be an unavoidable necessity, even in the case of the “least worst option”. This is another factor of consideration that is easily overlooked. Practically speaking, this means that there may not be much of a difference pipeline-wise between fetching from a pinned commit version, and bundling the source code of that commit, as the steps afterward should be similar.
