3 ms·

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

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.
- Mikhail_Edoshin 7y ago
  There's the #line directive that can keep the original file names and line numbers.
paulddraper 7y ago
> 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 7y ago
  Interesting, thank you! Are there any ways of doing that sort of distribution header-only then, rather than single file?

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.

Mikhail_Edoshin 7y ago
There's the #line directive that can keep the original file names and line numbers.

paulddraper 7y ago

> 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 7y ago
Interesting, thank you! Are there any ways of doing that sort of distribution header-only then, rather than single file?