forrestthewoodsHere is my best attempt to articulate why I believe all dependencies, including compiler toolchains, belong in version control.
https://www.forrestthewoods.com/blog/dependencies-belong-in-version-control/
Very Human Robot@forrestthewoods
I largely agree. I go so far as to check in generated code, because it both saves other people time, and it reduces opportunities for skew (and unexpected diffs show where there's a problem!)
You'll need the system image too with all the system libraries. At some point, is better to archive the entire disk. Use a well defined VM (or container) for building, so it's reproducible forever!
@StompyRobot I’m also a fan of committing generated code. Makes things easier to search. Can cause merge pain though.
I think it’s potentially worth having a full system image. But if you commit full toolchains it is largely unnecessary!
@forrestthewoods
You'll want the runtime libraries the toolchain uses.
Libc versions, .net runtime versions, msvc dll versions, ...
Sadly, most of this isn't statically linked.
Btw, if you get a conflict in the generated code, just blow away upstream, because you have the current source version and generation is deterministic. (Right?)
(If this doesn't work, you have some determinism problems to fix!)
@StompyRobot correct. When I say commit the full toolchain I really do mean everything in the Visual Studio/LLVM/etc directory! All of it!
Yeah re-generating code should definitely work. But it can make VCS cranky when it fails to cleanly merge/rebase and it wants to run merge tools or inject conflict markers.
Ideally VCS knows what files are generated and how to regenerate them. But that’s a separate story!