8 ms·

I've done something different before: // main.c #include <module.c> int main() { moduleFunction(); } // module.c #include

I've done something different before: // main.c #include <module.c> int main() { moduleFunction(); } // module.c #include <stdio.h> void moduleFunction() { printf("calling modules"); } This has its issues (you can't do parallel compilation anymore; you don't have unexported functions, etc), but it works fine for small things. Super helpful when I want to make a small thing and don't want to bother with headers. You just include all the C files in one file and be done with it.

actionfromafar 4y ago
It also automatically enables "global optimisation" in most cases. This style is called "amalgamation" and SQLite is distributed (but not developed) in this way.
- unsafecast 4y ago
  TIL it has a name. Doing what sqlite does gives you the best of both traditional and single header projects I imagine.
- RicoElectrico 4y ago
  Does this impose limitations on the code? I think all functions, even private, should be "namespaced" (i.e. in C - prefixed) then? Kind of awkward, but otherwise amalgamation is a great idea.
  - OskarS 4y ago
    C doesn't have "private" functions in that way, what it has is "static" functions, and this is indeed the biggest limitation of doing this kind of amalgamated build. If you mark a function as static, it means that has internal linkage and is only visible inside the translation unit was defined and no symbol is exported for linking. This is not the default: if you just define a function with some name, that symbol is in general visible to all other translation units that gets linked together by the linker (though with no type information attached, just the name of the symbol. Making sure the type information is correct is the purpose of header files). That means you can have any number of functions marked static in different translation units with the same name, and it's fine, they don't see each other. If you're doing an amalgamated build like this, that no longer works: all symbols have to have globally unique names. In addition, of course, you don't get the "separation" that "static" provides. You can't call a static function across a translation unit boundary, but since this just one big translation unit, anything goes: all functions can call all other functions, even if they shouldn't.
  - arinlen 4y ago
    > Does this impose limitations on the code? It does. Any technique that relies on features specific to translation units, such as taking advantage of internal linkage to reuse symbols to hold data specific to translation units, cannot be used anymore. Also, even though global builds are faster, you forego the ability to do incremental builds which makes working over a bug a more time-consuming task.
- arinlen 4y ago
  > This style is called "amalgamation" and SQLite is distributed (but not developed) in this way. These are actually called "unity builds" or "jumbo builds", and some build systems such as CMake offer support for this. https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.htm...
formerly_proven 4y ago
For smaller C++ projects this tends to be way faster than the conventional wisdom of having many CUs, mostly because all the library bloat will only be parsed and instantiated once.
- kringerkat 4y ago
  Also reduces link time. I find that projects up to around 50K lines compiles instantly as a single file/"unity build" and is my preferred way for most of my projects.
  - arinlen 4y ago
    > Also reduces link time. It's important to stress that it does more than reduce link time: unity builds completely eliminate linking when plugging together submodules, and the final project linking simply has far fewer object files to link.
- Asooka 4y ago
  This really should be solved at the compiler level, rather than forcing people to restructure their projects.
jariRG 4y ago
Afaik this is exactly what Unity builds are. https://en.wikipedia.org/wiki/Unity_build https://en.wikipedia.org/wiki/Unity_build
- unsafecast 4y ago
  Yeah. Though most projects still use header files with unity builds, so I decided not to call them that. It wasn't the concept of a unity build that I was emphasising, it was the idea of not forward-declaring everything.
  - arinlen 4y ago
    > Yeah. Though most projects still use header files with unity builds, so I decided not to call them that. There is nothing inherently special in header files. They are just a convention where you use a specific extension in source files you mostly use to pass declarations. Nothing stops you from using the .c extension on all files, and there is nothing special in passing declarations in one place and definitions in another place.
    - unsafecast 4y ago
      Of course! But, saying 'unity build' puts emphasis on the fact that you compile all the C files 'in unity', in a single CU. What _I_ wanted to put emphasis on is that you can skip the header files, and that coincidentally means you also have to unity build. The fact that most unity built projects still use headers made me hesitant to use the term, as that would put emphasis on building a single CU, as opposed to not forward declaring in headers.
- TingPing 4y ago
  Build systems like Meson can even enable/disable this with an option ootb.
agent281 4y ago
I never really had a good grasp of C. Why is this code novel? It looks like importing a function in any language.
- phaer 4y ago
  It's including another C file, normally you'd just include a "header file" in C and compile each C file separately.
  - usrn 4y ago
    For those who don't use C: header files are more or less an interface description and (usually) don't include any code. The code is added from external objects during the second "linking" step.
  - agent281 4y ago
    Oh, I see: including a header file injects forward declarations into the calling file. Each c file gets compiled separately into object code unless you directly import them like the code above is doing. In that case it essentially dumps the full text of the file into the calling file, which causes serial compilation of a single object file. Unless I'm mistaken that clears some stuff up for me. Thank you!
    - phaer 4y ago
      That's my understanding as well, so I think you are correct but I am no C wizard myself :)
- arinlen 4y ago
  > I never really had a good grasp of C. Why is this code novel? It looks like importing a function in any language. Unity builds are a very old and widely established concept. I dare to speculate they are older than the regular header and source file split, as C required a full blown preprocessor to split code in separate files and also someone had to come up with the include guard trick to get around the limitations of including the same definition multiple times. They aren't employed that often because there are some tradeoffs and in large projects it's benefitial to split them in smaller translation units to limit the scope of incremental builds.

actionfromafar 4y ago

It also automatically enables "global optimisation" in most cases. This style is called "amalgamation" and SQLite is distributed (but not developed) in this way.

unsafecast 4y ago
TIL it has a name. Doing what sqlite does gives you the best of both traditional and single header projects I imagine.
RicoElectrico 4y ago
Does this impose limitations on the code? I think all functions, even private, should be "namespaced" (i.e. in C - prefixed) then? Kind of awkward, but otherwise amalgamation is a great idea.
- OskarS 4y ago
  C doesn't have "private" functions in that way, what it has is "static" functions, and this is indeed the biggest limitation of doing this kind of amalgamated build. If you mark a function as static, it means that has internal linkage and is only visible inside the translation unit was defined and no symbol is exported for linking. This is not the default: if you just define a function with some name, that symbol is in general visible to all other translation units that gets linked together by the linker (though with no type information attached, just the name of the symbol. Making sure the type information is correct is the purpose of header files). That means you can have any number of functions marked static in different translation units with the same name, and it's fine, they don't see each other. If you're doing an amalgamated build like this, that no longer works: all symbols have to have globally unique names. In addition, of course, you don't get the "separation" that "static" provides. You can't call a static function across a translation unit boundary, but since this just one big translation unit, anything goes: all functions can call all other functions, even if they shouldn't.
- arinlen 4y ago
  > Does this impose limitations on the code? It does. Any technique that relies on features specific to translation units, such as taking advantage of internal linkage to reuse symbols to hold data specific to translation units, cannot be used anymore. Also, even though global builds are faster, you forego the ability to do incremental builds which makes working over a bug a more time-consuming task.
arinlen 4y ago
> This style is called "amalgamation" and SQLite is distributed (but not developed) in this way. These are actually called "unity builds" or "jumbo builds", and some build systems such as CMake offer support for this. https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.htm...

formerly_proven 4y ago

For smaller C++ projects this tends to be way faster than the conventional wisdom of having many CUs, mostly because all the library bloat will only be parsed and instantiated once.

kringerkat 4y ago
Also reduces link time. I find that projects up to around 50K lines compiles instantly as a single file/"unity build" and is my preferred way for most of my projects.
- arinlen 4y ago
  > Also reduces link time. It's important to stress that it does more than reduce link time: unity builds completely eliminate linking when plugging together submodules, and the final project linking simply has far fewer object files to link.
Asooka 4y ago
This really should be solved at the compiler level, rather than forcing people to restructure their projects.

jariRG 4y ago

Afaik this is exactly what Unity builds are. https://en.wikipedia.org/wiki/Unity_build https://en.wikipedia.org/wiki/Unity_build

unsafecast 4y ago
Yeah. Though most projects still use header files with unity builds, so I decided not to call them that. It wasn't the concept of a unity build that I was emphasising, it was the idea of not forward-declaring everything.
- arinlen 4y ago
  > Yeah. Though most projects still use header files with unity builds, so I decided not to call them that. There is nothing inherently special in header files. They are just a convention where you use a specific extension in source files you mostly use to pass declarations. Nothing stops you from using the .c extension on all files, and there is nothing special in passing declarations in one place and definitions in another place.
  - unsafecast 4y ago
    Of course! But, saying 'unity build' puts emphasis on the fact that you compile all the C files 'in unity', in a single CU. What _I_ wanted to put emphasis on is that you can skip the header files, and that coincidentally means you also have to unity build. The fact that most unity built projects still use headers made me hesitant to use the term, as that would put emphasis on building a single CU, as opposed to not forward declaring in headers.
TingPing 4y ago
Build systems like Meson can even enable/disable this with an option ootb.

agent281 4y ago

I never really had a good grasp of C. Why is this code novel? It looks like importing a function in any language.

phaer 4y ago
It's including another C file, normally you'd just include a "header file" in C and compile each C file separately.
- usrn 4y ago
  For those who don't use C: header files are more or less an interface description and (usually) don't include any code. The code is added from external objects during the second "linking" step.
- agent281 4y ago
  Oh, I see: including a header file injects forward declarations into the calling file. Each c file gets compiled separately into object code unless you directly import them like the code above is doing. In that case it essentially dumps the full text of the file into the calling file, which causes serial compilation of a single object file. Unless I'm mistaken that clears some stuff up for me. Thank you!
  - phaer 4y ago
    That's my understanding as well, so I think you are correct but I am no C wizard myself :)
arinlen 4y ago
> I never really had a good grasp of C. Why is this code novel? It looks like importing a function in any language. Unity builds are a very old and widely established concept. I dare to speculate they are older than the regular header and source file split, as C required a full blown preprocessor to split code in separate files and also someone had to come up with the include guard trick to get around the limitations of including the same definition multiple times. They aren't employed that often because there are some tradeoffs and in large projects it's benefitial to split them in smaller translation units to limit the scope of incremental builds.