> From: Troy Laurin [mailto:[EMAIL PROTECTED] > > On 10/20/05, Anderson, Kelly <[EMAIL PROTECTED]> wrote: > > As a follow up question though... about the "clean" target, does the > > clean target typically delete the source files so that they > have to be > > retrieved from revision control by scratch, or just the > obj, lib, exe > > and other intermediate files? Do you have two separate > targets for these > > different levels of clean? and how do you typically use the > two levels? > > I'd suggest that the two levels of "clean" you are talking about > belong in different conceptual spaces...
Clearly. > Clean, as I would normally understand it, means to delete all derived > files - obj, lib, exe, class, etc... all files that are dynamically > generated by the build process. I guess the CM holy grail is that > after a fresh checkout, "build" then "clean" will leave the source > tree unmodified from the checkout.* 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. I guess what I'm saying is that an "intermediate" file is somewhat open to interpretation. > 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. > * - This is usually pretty simple to achieve if you can ensure that > all derived files are generated in a directory (say bin) that isn't > placed in source control... then the clean target simply has to delete > this directory. Note that this implies that if you dynamically > generate or modify source files (eg- AssemblyInfo.cs), the > build-modified files would be placed in, say, bin/src and have to be > included in the build from there. 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. > The other level of clean is I think restricted to the notion of > continuous integration. If you think of the CI "build" being updating > the source tree from source control and then running a build, then a > CI "clean" could be removing the source tree. > > In practice, if your main build script can clean the project > effectively (holy grail style), and updating from your source control > system propagates file additions and deletions as well as > modifications, then a CI "clean" shouldn't be necessary. On the other > hand, if your main build script involves modifying source files in > place, or generates files where they can't easily be cleaned, then it > may be simpler to delete the source tree before updating from source > control to ensure that each CI build is pristine. This seems reasonable. > 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. Thanks for an interesting discussion. -Kelly E-Mail messages may contain viruses, worms, or other malicious code. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective action against such code. Sender is not liable for any loss or damage arising from this message. The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this e-mail by anyone else is unauthorized. ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Nant-users mailing list Nant-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users
