* 25 million lines of C/C++ code in one Git repo
* Mission critical code
* Statically linked except for system/libc etc
* No cross compile. Apart from debug v. release builds there's one target arch: Intel x86_64 Linux
* Management wants assurance all code built without skipping files and/or missing a link; want automatic and correct-by-construction build process wherever possible. Do not want devs abandoning files not used etc etc [1]
* Devs add (periodically remove) libs. Code changes all the time
* things not in scope: Xcode/Vstudio or anything that wants to configure in a IDE. Solution must be 100% at command line
Coarse first cut solution:
* Mandate official dirs holding code e.g. src/lib, include
* Mandate meta file format and content which describes library's dependencies. This is manual and therefore we accept it's an opportunity defect. Thankfully library additions smallish, and once OK, stay OK mostly. Anyway risk non-zero here.
* Mandate where unit, integration tests go
* Mandate where tasks (things with 'main()') go
* Mandate file names e.g. if 'foo.c/foo.h' is part of a library 'Infra' we expect to see 'src/lib/infra/src/lib_infra_foo.c, src/lib/infra/include/lib_infra_foo.h' so that file names are somewhat self describing
* Write script to roll-up above outputting a CMakeLists.txt (or ninja etc) input. From there a real Makefile follows with build flags
* CI test rejects PRs with source outside official dirs or failing org structure
* In sum directory structure and content induce a lot of what's built. What the structure cannot say is deferred to meta data files. This solution makes an argument that so long as the meta data is right, the build system will reflect the number and structure. Compilation and linker errors flush out the rest.
Exotic additions could include:
* clang ast passes to insure public code in lib_infra_foo.c has callers somewhere (we provide switches to gcc so the linker excises code not called in a lib too)
* verify builds for header inclusion correctness e.g. build src/lib/infra/src/lib_infra_foo.c and inspect that it's first include is src/lib/infra/include/lib_infra_foo.h and all headers it drags in are actually used
Does anybody have a better first-cut idea or think libs as C++ modules will hit a sweet spot?
[1] There are ways to argue with or against management. In the master craftsman sense, devs don't need handholding. As source/libs are added or removed devs will update Cmake (ninja) build files and ... case-closed. In the palpable-fear sense, management and release managers want some assurance things are organized smartly. Devs are help no doubt, but devs sometimes screw stuff up. Better to be sure. In this post the motivation isn't salient. Engineering a reasonable solution is.
"Management" seems too worried about the wrong optimizations.