The author of that article is overly focused on the Linux (or similar) deployment model, which most definitely does not cover all uses of SQLite. The argument against 2) also depends on a feature available in specific versions of specific compilers, which again, a piece of software that supports as many use cases as SQLite can’t depend on.
Even in that model, I’ve long found that the arguments against 1) are weak in practice (especially with a well-designed and maintained lib like SQLite) versus the additional complexity added by depending on dynamically linked libraries.
I wouldn't put up with 2min build times if I could avoid it. There are incremental compile/link options though, right? For that matter, I could also use the < 32K source-line files instead of the all-in-one if it saved me time.
seems like the tl;dr is: the amalgamation is stupid because 1.) it takes longer to build than it would if it wasn't an amalgamation and 2.) zip files instead of tarballs is somehow discriminatory against linux users(?). it's as though the author missed the entire point of the amalgamation to begin with, i.e. so you can easily embed sqlite directly into your application, in scenarios where your reason for doing so outweighs the cons of foregoing using shared libraries (i.e. embedded). basically, linux guy is disproportionately outraged that the sqlite amalgamation takes a minute to build because of intentional choices made to simplify cross-platform and "incorporated" builds instead of just doing everything The Linux Way. it's not difficult to see why the amalgamation exists given C's lack of a well-defined cross-platform build system and the massively wide array of platforms and situations sqlite is used in production in.
