2

I'm using a code generator which has the following workflow:

  1. Configure stuff
  2. Generate code
  3. Modify generated code with user code at specifically annotated positions.

If changes are required to the configuration, the user code will remain after generating the code again because the annotated positions are untouched by the code generator.

My problem is, how do I properly put this into version control and into a build process?

Idea 1

Put configuration and generated code with user changes into version control. This is the easiest to integrate with the current build tools. However, the configuration and generated code might diverge. To mitigate that, the build process might generate the code again and verify that it's the same as the committed code.

Idea 2

Put just configuration and user changes into version control. This way, no generated files are stored in version control. The user code should then somehow be developed separately and automatically integrated into the generated code later.

For the curious, the code generator is Dave 2, although it's not really relevant for the question.

In my opinion, this question is ontopic, because it is about using a Tool in a Software Development Workflow.

1

Fully observing the Don't Repeat Yourself principle would mean that you shouldn't store any information twice in your repository. If you auto-generate source code (or any kind of file, really) and then tweak it further, the only way to fully comply is to store the templates that drive the generator, plus a diff between its output and the actual files you want.

But DRY is not a cosmic law. It is an idea that experience has show to have a lot of merit in many cases. Whether or not it has merit in your case depends on the particulars of your code base. Do you often re-run the generator? Is the output huge? Is there a lot of danger that you might forget to re-apply one of the tweaks in a future iteration? Those are the kind of questions you need answered to decide whether to be fully DRY, or whether to break that principle deliberately, knowing that its cons outweight its pros in this case.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.