Generated code under source control?
My Fabric project (which is coming along well BTW) is a formula compiler and runtime meant to be used with my object database (CouchDb). It uses Anltr to generate C++ compiler code from grammars I wrote. I have it set up so that everytime a build is run, it checks to see if the generated files cpp and hpp are out of date with the grammar, and if not it runs Antlr to generate the source files.
Currently I have these generated files included in the Visual Studio project solution browser and I have them under source control (Subversion). Neither is necessary, but it is convenient. I can't think of any problems this will cause, but sometime somewhere I seem to remember someone frowning on the practice. I just can't remember who or why. Anyone have a good reason not to do it this way?
(BTW I haven't been blogging much lately because I've been too focused on coding)
Posted December 6, 2005 3:13 PM
Comments
It's usually considered to be bad to have generated source checked into source control for the same reason that you don't check in binaries. The build process produces the files so they're a build result, not managed source code. That's the purist ideal.
But checking in build results can also cause problems with the build itself, if for example, it can't overwrite files under source control. Or you forget to check in the new CPP/HPP files when you change the grammar. Or other similar ills. That said, on a single developer project I don't think it's really going to matter too much.
Bob, December 6, 2005 7:58 PM
What Bob said; particularly if it's difficult for maintainers to tell what's generated and what's genuine.
ISTR that The Pragmatic Programmer covers (and frowns upon) this as an illustration of their Don't Repeat Yourself credo.
James Kew, December 6, 2005 11:22 PM
Actually there are benefits to checking in pdb, obj, lib and other binary files that are compiler/linker generated; these advantages become particularly of interest as you start to make formal public builds and need to debug/reproduce issues which were reported against a particular release without having to assume that your code re-generation process from a particular source label will produce files that are binary identical to what is released. I have seen issues in the past where recompiling older sources with a development environment that had a service pack applied produced output files which were optimized differently than the original files.
Just my thoughts.
Dana Zircher, December 7, 2005 7:19 AM
Good work Katz
Anonymous, December 7, 2005 8:42 AM
Dana - you bring up a good point, it's definitely a good idea to have a copy of released builds in their binary form. However, that's really a different issue.
If you have a generated file that doesn't change often, I think it's fine to have it under source control. If you have a generated file that changes all the time it's probably not worth the hassle unless your build scripts can handle checking the file out automatically (or you run a system that doesn't require checkouts, not sure which type Subversion is).
After all, as long as everything that is required to generate the file is under source control, you can't "lose" that file.
Nate Finch, December 7, 2005 9:39 AM
Ok, so the one big drawback is the potential for spurious merge conflicts on the generate files. But that's only a problem when a team is working on a project, but not when its just me alone. For now I'll keep the generate files in version control.
Damien, December 7, 2005 12:56 PM
Post a comment