> That is why the command line used to compile the assembly should be > saved and checked. If you changed the build file and it causes a > command line setting to be changed the build will get executed. This > gives you exactly what you are getting by depending on the build file > except that if you also change something unrelated to the build (like > add a comment) the build will not get executed.
Yeah - I see it now. Thank for clarification. Where store that information? One global file per system? Or one per .build file? Or one per build target? We have several files build in one .build project and many nested projects - so there will be a lot of temp files... Ok. Lets leave it open for now. Could you commit the other changes? (path checks in nested builds) Martin > > > BTW: I do not like to "nant clean;nant" every time I change > > build file during devel of this. It's not so much problem to > > add "rebuild" rule anyway... > > > > BTW2: Many commercial environments do rebuild when project is > > changed. This is case of "for sure" rule - user could be very > > confused, when he e.g. enable <Debug property> in project and > > his debugger refuse to debug. And property task is not direct > > compile task - so isolating of <csc> into another file do not > > help. I see - there are much more cases where recompile is > > not needed, but... that few could confuse user a lot. ______________________________________________________________________________ Nejširší nabídka PC komponent v ČR - http://www.levi.cz Neváhejte a srovnejte možnosti dnešního hardware. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
