Bonio Lopez wrote: > Hi Gary, > >> What happens if you just make a change to p22? How would you rebuild it >> > without rebuilding the rest? > I am sorry, but I don't understand where is the difference to the current > approach. The nant will run over all projects and see that p1, p11, p12,p13 > are not changed. So it will not rebuild those. Then it will see that p21 > changed and will rebuild it, it also will see that p22 and p23 are not > changed. > NAnt, per se, doesn't do that. Individual tasks within NAnt will do that. That means that you're still going to fire up each of the NAnt build files. If you use, for example, a number of <csc> tasks, then each one will do its own dependency analysis, which means redundant opening and closing of files.
Alternatively, you could just put them all into a single solution file, which will get all of the dependency analysis done at once. But that would mean making the solution task smart enough to do compilations in parallel, or alternatively, just letting Microsoft worry about doing that in msbuild. > I don't see any problem. > > Suppose someone introduces a dependency between p21 and p22. What are the > implications for your build process? Do you have to manually change the > build script? > Yes, but with current <nant> task it is the same. Right? So I see no new > No, it's not the same if you use solutions. You wouldn't have to change anything. But with NAnt doing the work, it's important to have the parallelism integrated with the dependency analysis. Just allowing the NAnt task to build multiple sub-NAnt projects in parallel doesn't quite do that. > implications. Currently you need to pay attention that you build p21 before > p22. i.e. that in the <nant> task you include p21 before p22. It would be > even simpler using "order" attribute. You would only need to change this > one. > True, but I dislike anything that permits allows things to execute in an order other than top to bottom. I'd rather see group markers, and just move the file to an earlier group. > Have you looked at using CruiseControl.Net for this? > Yes, I did. Indeed, it could be solved by CC. But it seems to me to be a > workaround and overkill (may be I am wrong), to use the second tool in order > to organize a build process. BTW Gmake also have switches for > multithreading. > It's not overkill at all, nor is it a workaround. It's a separation of concerns. It's much easier to maintain the programs (i.e. maintain NAnt and CC.Net) if one program is responsible for managing the parallel execution, while another worries about having finer grained control and a rich, extensible set of tasks. I encourage you to revisit this. The difference between NAnt and gmake is that NAnt has a two-tiered dependency analysis, while gmake just has one. With gmake, the dependency analysis is done globally, and then individual tasks executed. With NAnt, the targets are first ordered, but then the individual tasks do their own analysis about what to do. It's not clear to me whether one is better than the other, but it is clear that we can't assume that a tactic that works for one will be as effective in the other. At a minimum, I'd prefer to see some more study. Enough people have told me that parallel gmake is more trouble than its worth, that I've always avoided it for running on a single system. It's too easy to thrash, and there are a number of tools that weren't designed to be run in parallel on the same code base. I consider it mostly useful for doing remote executions in parallel. Gary ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ NAnt-users mailing list NAnt-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users
