Ive used sqlite a lot in recent years and found the issue you describe to be largely one that only affects Windows deployments. On Linux, FreeBSD, Solaris and OS X builds it's all just worked for me. But the same build scripts will fail for a multitude of subtle ways on Windows. IIRC (I've not targeted Windows much recently) I've found the easiest way to get it working was just to have mingw (or similar POSIX layer) and build sqlite from within that.
As with most things, your mileage varies a lot based on what you are used to. The previous poster mentioned "cross-platform" and I think that is where the most headaches lie because you might know one permutation, but not all of them.
For instance, Windows binary deployments are quite predictable (and often dead simple; so easy a lot of Windows installers get it wrong and yet still work), but on *nix you may have to fight distro differences in libc or get a dozen different answers on what you should statically link in your compile versus what you "must" dynamically link and a half-dozen different installers/bundlers/distro tools to deal with making sure the shared libraries are both installed and correctly linked to. What "just works" is often relative and the magic is very easily dispelled in that terrible state of "why isn't this working?", especially if it "just works" like magic for other people.
For what it is worth, the Windows UWP platform even bundles a shared SQLite install (as like Android and iOS) and using it is quite easy in a bunch of languages (just not easily portable cross-platform).
> For instance, Windows binary deployments are quite predictable (and often dead simple; so easy a lot of Windows installers get it wrong and yet still work), but on nix you may have to fight distro differences in libc or get a dozen different answers on what you should statically link in your compile versus what you "must" dynamically link and a half-dozen different installers/bundlers/distro tools to deal with making sure the shared libraries are both installed and correctly linked to. What "just works" is often relative and the magic is very easily dispelled in that terrible state of "why isn't this working?", especially if it "just works" like magic for other people.
That's only if you're working with C / C++ though. Switch to Go, Java or basically nearly any other language, and most of your cross platform headaches go away.
Though for what it's worth, half those problems aren't really problems you'd generally have to get your hands dirty with as your tooling and distro should manage that for you (just so long as you write POSIX code that is). I'll grant you I've not done anything too complex in C++ but what I have done was portable between Linux, Solaris and FreeBSD (the 3 systems I needed those POSIX C++ programs to target).
That was compiling on those respective platforms rather than compiling for those platforms then packaging them up for deployment. I've written a lot of code over the last 30 years and shipped it in a plethora of different ways and creating installers has historically definitely been easier on Windows. No question. Go lang is helping somewhat in that it's now really easy to ship a dependency free binary. But Windows is only one platform and one that creates more problems for cross-platform portability than all of the rest of the big platforms put together.
> For instance, Windows binary deployments are quite predictable (and often dead simple...
It's neither predictable, nor simple nor easily portable when it's about a mixture of managed (C#, Java etc.) and native (C, C++, asm etc) code. I'm happy to know the Windows UWP platform finally has it built-in but I code WinForms and console apps targeting Windows 7 + Mac and Linux with Mono and using SQLite always means a problem (yet I always want to use SQLite to store anything (except just some things that obviously fit other ways of storage better) because it's great and it's a standard supported everywhere).
I'm not sure if it's related to the .Net framework, but definitely it's NOT related to the Windows platform. I've been using SQLite on Windows (with Delphi) for nearly a decade, while there were issues (solvable), but one is related to deployment, seriously.
