thanks for taking the time to put together a detailed response. I appreciate it.
I agree with you on the difficulties of authoring Xml - however I don't find editing NAnt build files to be to bad with decent schema based code completion. Writing control-flow in a language like xslt however is a real PITA.* Using XML to express the build rules is, IMO, too heavyweight. I can see how it's easy to parse and gives an easy mechanism for interfacing with tasks, but writing a build file is like programming in any other language; it's better to have the common bits easy and the rare bits hard than everything somewhere in an awkward medium.
* The replacement of shell commands with tasks is important, ofyou can paramatise according to platform of course. Is it your opinion that the build tool should decide extension based on platform - ie the user just specify's foo and the extension is added automatically ?
course, but the commands still seem on the low-level side of things: copy file, delete file, compile to this file; what happens if I'm compiling foo.so on Linux and foo.dll on Windows?
Somthing else to mention is that NAnt probably isn't being used to comple much c code - its far better suited to / and designed for compiling with the .net compilers. I know you're going to say "hey its a build tool isn't it - it should be able to handle C code" and thats a fair point, but up till now NAnt has been very much a product of its initial problem domain - building .Net projects, in the same way that Ant is still primarily a tool for building java apps.
* I haven't seen indications that it's particularly aware of recursion.Could you elaborate on what recursion awareness means in this context ?
What would you have in mind exactly ? This hasn't really been a problem up till now. Maybe we don't have enough tasks yet. Still this is a packaging issue rather than a core build issue isn't it ?* It looks like you can implement tasks in user assemblies but I don't see a framework for distributing them sanely (which I believe to be very important: aclocal, anyone?)
no. And this has never been a goal. Your point above about the choice of xml is probably warranted here. Defining tasks in xml would likely be pretty painful. However the current method of authoring custom tasks in .Net languages seems to be fine for most users.* Similarly, it doesn't look like you can define tasks in the XML itself.
* You still have to write your own clean rules and dist rules.hmm - thats a good idea. Have each task define what its outputs are and then use that info to do the clean. Dist however could be getting files from anywhere. At least if you define the dist rule yourself you can see at a glance what files you're getting and from where.
Surely the tool, knowing the targets and all the rules used
to build them, could figure this out by itself?
hmm - I've used other build tools - cons ( http://www.dsmit.com/cons/) which do use MD5 sums. With large source trees there was a significant time taken to calculate which files need re-building. This could just have been a feature of cons and not of using MD5 sums - I'm not necessarily defending NAnt on this point.* Still using file modtimes, not MD5 sums, as criteria for rebuilding. Not the end of the world, but if you change a comment in a C file and have to relink your executable as a result, it can be a drag.
as Jaraslaw metioned - config info is stored in a config file. However elements of the configuration can be overridden on a per build file basis.* Judging from idea of build properties, configuration state is still kept outside of the build tool.
I'd like to hear more of your thoughts in this regard. Be sure to post here when you get your project off the ground.NAnt seems to improve on the implementation of make while still working within the same basic framework. My opinion is that there's a lot to be gained from really rethinking what it means to "build" something and structuring the process a lot more.
Fair point. Things like re-buildability calculations are all calculated by the tasks themselves. You are right in saying that there should be support for this in the core of the tool itself.To try to articulate that idea a bit more, here's a quote from the NAnt webpage that struck me:
Important: Some tasks like the compiler tasks will only execute if the date stamp of the generated file is older than the source files. If you compile HelloWorld project in debug mode and then try to compile it again in non-debug mode without first cleaning nothing will happen because NAnt will think the project does not need rebuilding.
Ian
_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
