[t43562]

After writing build systems for a C/C++ operating system and years optimising builds for C/C++ operating systems the major disaster by far is the C preprocessor.

This is the source of all the evil. Even a hello world program involves reading through 100s of kilobytes, often megabytes, of headers that have to be parsed again and again for every source file but which can produce totally different outcomes in each case depending on compilers and the OS and the definitions on the commandline and whatever's defined in the source code itself and how the filesystem is laid out.

You can forget managing the dependencies on large projects this way - they are overwhelming. Every build system tends to be leaky and imperfect to not get drowned in dependencies and the fanciest systems all tend to have big holes here or there or they have to use huge "catchall" dependencies to try to be correct at the cost of efficiency.

I hoped modules would remove this problem but so far I'm not sure. I'd love to get the opinion of someone who has used them. My read-ups about it didn't seem that hopeful - I got the impression of them being a bit like pre-compiled headers.

[10000truths]

C/C++ sucks to write dev tooling (e.g. syntax highlighting, LSPs, static analyzers) for. Pretty much everyone leans on libclang for parsing because very few people are insane enough to try to reimplement a parser themselves, let alone all the GNU extensions. And even then, macros make robust parsing really difficult. Imagine trying to parse a file that contains two programming languages that can be arbitrarily interleaved at almost the character level. That's basically what C/C++ are.

[delta_p_delta_x]

Named modules (not header units[1] which are a workaround for libraries not-yet migrated to C++ standard modules) straight-up disallow exporting macros. Which is a good thing. I can't stand macros.

[1]: https://clang.llvm.org/docs/StandardCPlusPlusModules.html#he...