Builds often involve one tool generating a file that is consumed later by another tool.
In some cases, the intermediate file is source code to be compiled. (For example, SWIG, lex, and yacc all do this.) In those cases, users sometimes have a desire to modify the generated source before it is compiled. The need to do this most often comes up when developing something new and wrestling with problems in the code generation process.
Vesta makes this more difficult than make-style build systems. Every build must be a completely specified recipe for going from initial sources to final results. So how could a developer who needs to modify an intermediate file do so under Vesta?
SDL debugger could allow you to do it, but that wouldn't be repeatable. It would need to set cacheit=false on the result of the modification.
- User could supply an alternate file to replace the generated file and have SDL code optionally use it instead. But what happens if the input to the generator changes?
(JVK) i like this one. It's the simplest, and probably gets the job done assuming this is mostly for debug tweaks. I also think we should evalute the natural derived file, and print a message to the user with the generated sid path, to allow the user to validate their override.
- I also believe that the easiest thing is for the user to include the file they want to override in their sources. This makes much sense in SDL bridge systems which create bindings keyed by type of file.
- I would guess that accidentally including a derived file in your source set is a common mistake, so that message to the user mentioned above is important.
- User could supply a patch to modify the generated file after, but what if the generated file changes such that the patch no longer applies?
- Could we apply a more sophisticated merging algorithm than patch? RCS-style 3-way merge could work.
- User could specify a callback function in SDL that modifies the generated file before the next step is performed.