On 10/21/05, Anderson, Kelly <[EMAIL PROTECTED]> wrote: > Ok. So here's a middle ground question. Say that you have a code > generation scheme that generates source files from say an Excel > spreadsheet using templates (like CodeSmith), then those files are > compiled. If the generated source files were in revision control (so > that not everyone needed the code generator on their development > machines) then a clean build might delete those generated files, > regenerate them using the code generator, and compile them. Another > "level" of clean would just check to see if the generated files were > older than the spreadsheet and template files and only do the > regeneration if they were out of date.
That's a good question... more on this below. > I guess what I'm saying is that an "intermediate" file is somewhat open > to interpretation. I'd define a derived (intermediate) file as any file that can be completely generated from some tool based on other files under source control. > > Or to put it another way, if we > > were to do another "build", it would perform exactly the same steps, > > in the same order, with the same resuls, as the first build. > > This would be true even if "clean" deleted all source files and did a > get from revision control. Indeed it would! But it's a bit of a heavy-handed approach... > So I suppose this is your answer to the above question... that the > generated files should go in the bin directory. But, if some developers > didn't have code generation on their machines, not having those files in > revision control would cause some issues. That's an extremely good extension to the above question. In this case, where the generation tools aren't available to everyone (or not everyone wants to install the generation tools), then I would probably try to handle the generated files like a third-party library... check in stable builds of the generated files, possibly with other libraries, possibly in another "dependent" folder. The project using the generated files then wouldn't even include the source files any more... it would be pulled into a different project and someone (or a group) would be responsible for keeping the versions in sync and up to date. > > If I had a choice, and it were feasible, I personally would aim for > > the first (mostly because I'm a purist :-) But realistically, as long > > as something is in place that works (well enough), then improvements > > can come incrementally as they add value. > > Which "first" are you referring to here. I want to make sure I > understand what you're saying. The first approach in the paragraph above... separate clean-project and update-project targets, rather than the delete-and-update approach if source files are modified in place. > Thanks for an interesting discussion. > > -Kelly Always a pleasure :-) Regards, -- Troy ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Nant-users mailing list Nant-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users
