For projects of manageable size (say < 10,000 lines), I follow something like what ghp says. Rationale being, most PCs have plenty of memory so I compile my program as one big file and let gcc optimize what it wants.
Example: Main program is say foo.c and foo.h. Then I include a bar.c from inside foo.c. The bar.c file would be a sub-module, for example a collection of all code needed to drive an OLED. The CMakeLists.txt does not need to mention bar.c at all, gcc dependencies will take care of that. You can easily set up a test project to verify that it works, edit or touch bar.c and make should rebuild the project as expected if it tracks dependencies properly.
This kind of scheme used to be a quick and dirty way of making gcc do global optimizations, before link time optimization became more of a standard C compiler feature. Penalty is higher compile times -- not a problem with small projects -- and it also helps if you are more of a laid-back coder who does not expect very fast compile times.
Example: Main program is say foo.c and foo.h. Then I include a bar.c from inside foo.c. The bar.c file would be a sub-module, for example a collection of all code needed to drive an OLED. The CMakeLists.txt does not need to mention bar.c at all, gcc dependencies will take care of that. You can easily set up a test project to verify that it works, edit or touch bar.c and make should rebuild the project as expected if it tracks dependencies properly.
This kind of scheme used to be a quick and dirty way of making gcc do global optimizations, before link time optimization became more of a standard C compiler feature. Penalty is higher compile times -- not a problem with small projects -- and it also helps if you are more of a laid-back coder who does not expect very fast compile times.
Statistics: Posted by katak255 — Wed Feb 18, 2026 1:01 am