
SQLite is easy to compile - nikbackm
https://jvns.ca/blog/2019/10/28/sqlite-is-really-easy-to-compile/
======
pjc50
> But then I tried to run it on a build server I was using (Netlify), and I
> got this extremely strange error message: “File not found”. I straced it,
> and sure enough execve was returning the error code ENOENT, which means
> “File not found”. This was kind of maddening because the file was DEFINITELY
> there and it had the correct permissions and everything.

This is an infuriating property of the runtime linkers on both Linux and
Windows: if you're trying to load file A, and dependency B of file A does not
exist, you just get "file not found" with no indication of which file it was,
and it's extremely hard to debug. At least on linux the "show dependencies"
tool is built in.

~~~
lallysingh
There is also LD_DEBUG, which is quite helpful.

------
thomascgalvin
> All the code is in one file (sqlite.c), and there are no weird dependencies!
> It’s amazing.

This is because the author of SQLite publishes it this way as a convenience to
integrators; the actual day-to-day coding is _not_ done in a single C file.

In fact, the README[1] calls out twelve "key files", and explicitly warns that
SQLite "will not be the easiest library in the world to hack."

[https://sqlite.org/src/doc/trunk/README.md](https://sqlite.org/src/doc/trunk/README.md)

~~~
akhilcacharya
I'm not a C/C++ developer, but why can't more C/C++ projects be distributed as
source amalgamations? What prevents this from happening?

As in, source to source amalgamation rather than a more complicated build
system to generate a binary.

~~~
paulddraper
> why can't more C/C++ projects be distributed as source amalgamations

* Build time and memory increases.

* Debugger locations are less clear. MSVC debugging doesn't even work past 64KB lines.

* You still need to link it anyway when using as a library.

* Linker optimization has improved (especially clang).

* It's more difficult to modify.

SQLite has some decent reasons for it especially historically; I'm not sure
those reasons are as strong for other projects.

For applications, distributing binaries is even more convenient than source
code (assuming they exist for your platform).

And for libraries, "header-only" can be more of a convenience than "single-
file".

~~~
akhilcacharya
Interesting, thank you!

Are there any ways of doing that sort of distribution header-only then, rather
than single file?

------
chubot
Short Tcl script that combines everything into one file:

[https://www.sqlite.org/src/artifact/5fed3d75069d8f66](https://www.sqlite.org/src/artifact/5fed3d75069d8f66)

Some other details / rationale:

[https://www.sqlite.org/amalgamation.html](https://www.sqlite.org/amalgamation.html)

 _Combining all the code for SQLite into one big file makes SQLite easier to
deploy — there is just one file to keep track of. And because all code is in a
single translation unit, compilers can do better inter-procedure optimization
resulting in machine code that is between 5% and 10% faster._

------
bobochan
One of the benefits of this is Alon Zakai's wonderful compilation of the
SQLite C code with Emscripten to generate sql.js, which I have found very
useful for teaching SQL.

[https://github.com/kripken/sql.js](https://github.com/kripken/sql.js)

~~~
carapace
Awesome! "Web SQL Database" rides again!

[https://en.wikipedia.org/wiki/Web_SQL_Database](https://en.wikipedia.org/wiki/Web_SQL_Database)

------
dpcan
Yeah, so, this just blew my mind. I compiled it with an older version of gcc
that I had on my Windows machine and it worked just as easily (without
threading, or -ldl)

But there it is, a fully featured SQL engine in an EXE file that I can use
with any application I want.

In a world that requires a million SDK's, DLL's, dependencies, etc, this is
the most refreshing thing in the world.

------
enitihas
Being easy to compile is a very nice thing to have about any software. Redis
for example, is also too easy to compile, and quickly too. I think a lot of
software using autotools is easy to compile (atleast on the POSIX compliant
systems). Even postgresql is easy to compile, although not very quickly.

------
MuffinFlavored
> run ./configure > realize i’m missing a dependency

If only there was like, a tool, to help you manage compile-time dependencies.

I wish there was a `yarn` equivalent for C projects.

~~~
jkbbwr
This problem is 1000% harder than you think it is, and everyone has a
different idea on how to solve it.

~~~
MuffinFlavored
Sure, but like... `package.json` as a source of truth for dependencies
(package names + semver criteria to match) followed by abstracting fetch +
build away through one command `yarn install`

Those two concepts will always remain the same despite the underlying
workings, no?

~~~
progval
That's what distributions do. For example in Debian, the lists of build and
run-time dependencies are in ./debian/control

------
giovannibajo1
Another good example is the Go compiler. Assuming you have any version of Go
in your PATH, it's:

    
    
        git clone https://github.com/golang/go
        cd go/src
        ./make.bash     # or make.bat for Windows
    

And that's it. You can then use "bin/go" to compile your projects.

~~~
MayeulC
It's a whole lot more complex to run a build script like this than a simple
call to a C compiler, and has many more dependencies: you even need bash
installed, and it looks like the script would fail if the kernel isn't
compiled with selinux support... The script itself isn't that compilcated, but
complicated enough that I didn't want to spend too much time reading it.

Moreover, you cannot compare cloning a git repository with downloading a
single c source file... This seems equivalent in complexity to the good old
"git clone; ./configure; make"

------
mikece
The amalgamation file is a really interesting idea -- is this common in the
world of C applications? The documentation is quite clear, however, that the
amalgamation file and the source files are not the same thing. The source code
(1,848 files in 40 folders) can be pulled down here --
[https://www.sqlite.org/cgi/src/doc/trunk/README.md](https://www.sqlite.org/cgi/src/doc/trunk/README.md)
\-- but more assembly will be required if you're planning to build the
project.

UPDATE: maybe not so much assembly is required... just running "make" built
the project without any drama (I'm on macOS with XCode and tooling for Xamarin
already installed - YMMV in terms whether you might need to install something
to compile from source).

~~~
planteen
It's not common, but there are other projects like this for easy integration,
especially on embedded systems. You see some C++ libraries that are a single
header file include. And here is a collection of single file headers for
graphics tasks, like loading images, resizing images, rendering font glyphs,
etc:

[https://github.com/nothings/stb](https://github.com/nothings/stb)

------
amyjess
Every time an article about SQLite hits the front page here, I find myself
stunned at how well-designed it is.

------
setheron
I haven't checked yet but was curious if it post processes the file into a
single source file or that's how it's developed. The former sounds useful for
build (as her blog suggests) whereas the latter sounds frightening to audit.
(Unless it's written literate?)

~~~
thomasgt
I believe they use TCL scripts to generate the amalgamated .c file. Oddly
enough there is a post about TCL on the front page as I type this.

------
z92
It's far more easier. I had some sqlite2 database on an old system but nothing
to convert it or even dump it. Had to download sqlite2 source and delete all
_tcl_.c files. Then ran

    
    
        gcc *.c -o sqlite2
    

and it was done. That much simple.

------
MrZongle2
I love a happy ending!

(Especially when many of _my_ compiling-from-source experiences resemble what
the author was anticipating)

