[Mono-list] Mono Tools and Utilities

[Peter Williams]

On Mon, 2003-10-13 at 13:00, Ian MacLean wrote:
> Peter,
> thanks for taking the time to put together a detailed response. I 
> appreciate it.

(Jaroslaw, I tried to take into account the points you brought up in
here.)

Well, it's only fair.

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

Yeah, a smart XML editor would probably make things pretty
straightforward. Maybe I really just need to get better at Emacs' XML
support. Anyway, clearly the file format is not the most important
feature of nant.

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

Yeah this is true; but the filename extension thing is just one example
of why I don't think it's good for a build tool to work directly with
filenames. Another example would be supporting $(srcdir) != $(builddir)
compilations -- I don't know if you're familiar with the concept, but
the idea is to be able to keep all the built files in a separate
directory tree from the source files -- thus allowing you to say have a
debug build tree and a release build tree that are kept separate.
Anyway, to support this traditionally is very tricky since you have to
remember "ok does this file live in the source tree or the build tree?",
but a build tool that passes around references to files instead would be
able to avoid this.

> Could you elaborate on what recursion awareness means in this context ?

Say I have project/libfoo/ and project/program-that-uses-libfoo. If I'm
working in project/libfoo and rebuild it, will the program also be
relinked? [*] These kind of interactions get very messy -- take a look
at the evolution source tree some time.

[*] Of course with a huge source tree you want to be able to say 'don't
check everything, just rebuild here'

> 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 is packaging to some extent but I think support in the core build bit
could improve the situation. The problem is probably much bigger on
Linux where program interdependencies are a lot more numerous than on
Windows. (I am assuming you're primarily a Windows developer; maybe I'm
wrong.) Anyway, say your program has some configuration code to check
for kerberos support. That code needs to be distributed with your
program' sources in order for the check to work. But say the user's
system has an updated version of that code installed by a smart,
.Net-aware Kerberos distribution. This is where distributing the config
code as assemblies wins, because you get versioning and can choose the
proper assembly to use. But there would ideally be a mechanism to figure
out what tasks your project is using and bundle in the appropriate
(non-core) ones in the source tree. (Security would be something to
think about, but again, that's why it's good to keep tasks in
assemblies...)

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

I had in mind here the build system for mcs/ right now. We (sort of)
define some custom rules for compiling assemblies, but they're not
really as complicated as a whole new task -- more like a <csc> task with
some special options and moving the output directory, etc. It would be
convenient to be able to specify this as a grouping of several tasks...
and also I suppose there might be some kind of bootstrapping problem of
needing to compile the custom assembly task into an assembly before it
can be used to compile assemblies.

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

Yeah, dist is always tricky, but if you have a program that uses source
files a.cs and b.cs, you almost surely want to dist them, and you
probably don't want to have to remember to modify your dist list every
time you add a new file. Here Jaroslaw's named filesets might be pretty
useful, but then if you have built source files you need to remember to
exclude those files, and so on... I think the ideal system would be to
automatically distribute all the leaf nodes on the dependency graph.

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

I haven't really tried this myself but I could see MD5 sums being
time-consuming. I guess what really makes this useful is that it opens
up the possibility of having a target that isn't a file -- which then
lets you solve the issue of "not rebuilding when you change the debug
flag". The problem is that your program has a dependency on the debug
flag, but since it's not a file you can't really express it. As Jaroslaw
mentioned, you can make a stamp file and go from there, but if you had
25 boolean build options the amount of boilerplate code would get
obnoxious. 

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

What I was getting at was the above: the results of the build really do
depend on the configuration variables, but they're not quite first-class
<targets>, so you get something like the debug rebuild problem.

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

I'll forward an email with a summary of what I've done.

Peter

-- 
Peter Williams                          peter@newton.cx

"[Ninjas] are cool; and by cool, I mean totally sweet."
                              -- REAL Ultimate Power