6 ms·

> 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 co

> 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

BubRoss 7y ago
I'm not sure anyone thought that it was made that way, this is very explicitly for distribution and it works very well.
- eximius 7y ago
  In a vacuum, reading that statement, that was the assumption I made. Certainly strikes me as a bit odd, but then, SQLite is a bit of an odd project. And sometimes odd projects do things differently in a way that works out well because they have the discipline to pull it off. But it does make much more sense that it is worked on in pieces and then put back together.
zabzonk 7y ago
> the actual day-to-day coding is not done in a single C file. That's true - but in order for it be able to be reduced to a single C file, a lot of thought had to go into the process.
- jstimpfle 7y ago
  You just don't depend on weird libraries that mess up your preprocessor state. Then you make sure that even your static (file local) variables have unique names. And then you concatenate all the header and source files. It shouldn't be very hard, but most projects fail already at the dependency stage.
mhd 7y ago
There's quite a bit of build management going on with sqlite. Apart from that script, Dr. Hipp wrote his own source code management system[1] to fit his need and if I'm not mistaken they don't write headers by hand[2]. [1]: https://www.fossil-scm.org/ https://www.fossil-scm.org/ [2]: https://www.hwaci.com/sw/mkhdr/ https://www.hwaci.com/sw/mkhdr/
- thomascgalvin 7y ago
  Fossil intrigues me every time I see it mentioned. I've never found a sue for it, but it's so neat that I want to find a use for it.
  - j88439h84 7y ago
    The main features could be emulated with a small wrapper around git, no?
    - phamilton 7y ago
      A full web ui with issue tracker is a bit more than a small wrapper.
bch 7y ago
And also as a gift to optimizing compilers, from discussions I’ve had w him. The idea is that a single compilation unit (the “amalgamation”) is easy for the compiler to reason about.
- cozzyd 7y ago
  Sure, but now we have -flto, somewhat negating that advantage?
  - bch 7y ago
    Perhaps. Assumes all compilers support it, but otherwise, a testable case.
  - Glacia 7y ago
    Except LTO is slow to compile and SCU is fast.
akhilcacharya 7y ago
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.
- jandrese 7y ago
  For larger projects there is a danger of blowing out the memory on older machines when you combine everything into one monstrous C/CPP file. It's already impossible to compile Firefox on a machine with 1GB of RAM because some of the files are just too big. Even with swapping enabled the build process crapped out for me last time I tried it. While 1GB machines are pretty rare these days outside of SBCs, you could easily blow out a 4GB machine if you tried to compile the whole damn thing at once, and 4GB machines are still commonly found.
  - planteen 7y ago
    Is that much of a problem though? For SBCs like the Raspberry Pi you can do builds on the SBC itself. While this is neat, it is far from optimal because builds are very slow. It's much more typical for embedded systems to do you build on a host PC with a cross-compiler.
    - jandrese 7y ago
      Sometimes getting that cross compiler environment set up properly, especially with all of the dependencies and build tools, is more hassle than just letting the build run overnight on the SBC itself. Especially when it has a configure script that wants to check on various properties of the target architecture as part of the build.
- wkz 7y ago
  For one, I think this would be cumbersome from a debugging perspective. All of the address-to-source-mappings in your DWARF section would point to things like "lib.c:237652" instead of "lib-module.c:347". It also means that you're effectively linking all you dependencies statically. In some cases this can be a plus, in some cases a minus. I think having the choice is important though. I imagine there are lots of other parts of the toolchain that would have to be updated to support this workflow. Seems like a lot of hassle for something that, though at times complicated, mostly works.

BubRoss 7y ago

I'm not sure anyone thought that it was made that way, this is very explicitly for distribution and it works very well.

eximius 7y ago
In a vacuum, reading that statement, that was the assumption I made. Certainly strikes me as a bit odd, but then, SQLite is a bit of an odd project. And sometimes odd projects do things differently in a way that works out well because they have the discipline to pull it off. But it does make much more sense that it is worked on in pieces and then put back together.

zabzonk 7y ago

> the actual day-to-day coding is not done in a single C file. That's true - but in order for it be able to be reduced to a single C file, a lot of thought had to go into the process.

jstimpfle 7y ago
You just don't depend on weird libraries that mess up your preprocessor state. Then you make sure that even your static (file local) variables have unique names. And then you concatenate all the header and source files. It shouldn't be very hard, but most projects fail already at the dependency stage.

mhd 7y ago

There's quite a bit of build management going on with sqlite. Apart from that script, Dr. Hipp wrote his own source code management system[1] to fit his need and if I'm not mistaken they don't write headers by hand[2]. [1]: https://www.fossil-scm.org/ https://www.fossil-scm.org/ [2]: https://www.hwaci.com/sw/mkhdr/ https://www.hwaci.com/sw/mkhdr/

thomascgalvin 7y ago
Fossil intrigues me every time I see it mentioned. I've never found a sue for it, but it's so neat that I want to find a use for it.
- j88439h84 7y ago
  The main features could be emulated with a small wrapper around git, no?
  - phamilton 7y ago
    A full web ui with issue tracker is a bit more than a small wrapper.

bch 7y ago

And also as a gift to optimizing compilers, from discussions I’ve had w him. The idea is that a single compilation unit (the “amalgamation”) is easy for the compiler to reason about.

cozzyd 7y ago
Sure, but now we have -flto, somewhat negating that advantage?
- bch 7y ago
  Perhaps. Assumes all compilers support it, but otherwise, a testable case.
- Glacia 7y ago
  Except LTO is slow to compile and SCU is fast.

akhilcacharya 7y ago

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.

jandrese 7y ago
For larger projects there is a danger of blowing out the memory on older machines when you combine everything into one monstrous C/CPP file. It's already impossible to compile Firefox on a machine with 1GB of RAM because some of the files are just too big. Even with swapping enabled the build process crapped out for me last time I tried it. While 1GB machines are pretty rare these days outside of SBCs, you could easily blow out a 4GB machine if you tried to compile the whole damn thing at once, and 4GB machines are still commonly found.
- planteen 7y ago
  Is that much of a problem though? For SBCs like the Raspberry Pi you can do builds on the SBC itself. While this is neat, it is far from optimal because builds are very slow. It's much more typical for embedded systems to do you build on a host PC with a cross-compiler.
  - jandrese 7y ago
    Sometimes getting that cross compiler environment set up properly, especially with all of the dependencies and build tools, is more hassle than just letting the build run overnight on the SBC itself. Especially when it has a configure script that wants to check on various properties of the target architecture as part of the build.
wkz 7y ago
For one, I think this would be cumbersome from a debugging perspective. All of the address-to-source-mappings in your DWARF section would point to things like "lib.c:237652" instead of "lib-module.c:347". It also means that you're effectively linking all you dependencies statically. In some cases this can be a plus, in some cases a minus. I think having the choice is important though. I imagine there are lots of other parts of the toolchain that would have to be updated to support this workflow. Seems like a lot of hassle for something that, though at times complicated, mostly works.