Splitting up .cpp files for faster dev build turnaround times?

How’s the mood for splitting big .cpp files into smaller units? Say, for more granularity in compilation which cuts down development build loops, and may help overall build times if it helps parallelize.

So I was hacking on some tileset code. Build times were a bit slow as the whole of cata_tiles.cpp takes some time to build (which is understandable given its non-trivial nature). I tried extracting the functions I was working on into a new .cpp file and it helped a lot. CMake automatically picks up the new files. The change-build-run loop was a lot tighter. I re-merged the file before commit. I think I’ll be doing this for local development.

I think it might be useful to split some of the bigger .cpp files into subsets. Say, cata_tiles.h corresponds to cata_tiles.cpp, cata_tiles_subset.cpp, cata_tiles_anothersubset.cpp. Or something like this? It still feels a little unclear maybe.

I just wanted to check, yeah, what the general mood or consensus was on splitting .cpp files? Has this been discussed? Might make sense in some cases?

I’m all for it, as long as it makes sense. Splitting a class among multiple files is kind of icky, but I did it in the vehicles code and no one complained too much.

3 Likes