[Mono-list] Mono Tools and Utilities

[Ian MacLean]

Peter,
thanks for taking the time to put together a detailed response. I 
appreciate it.

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

>	* The replacement of shell commands with tasks is important, 	  of
>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?
>
>  
>
you 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 ?
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 ?

>	* 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?)
>
>  
>
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 ?

>	* Similarly, it doesn't look like you can define tasks in the
>	  XML itself.
>
>  
>
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.

>	* You still have to write your own clean rules and dist rules.
>	  Surely the tool, knowing the targets and all the rules used
>	  to build them, could figure this out by itself?
>  
>
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.

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

>	* Judging from idea of build properties, configuration state
>	  is still kept outside of the build tool.
>
>  
>
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.

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

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

Ian