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... 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.* 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 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. 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. 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. -- Troy ------------------------------------------------------- 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
