[Mono-list] Mono Tools and Utilities
Tue, 14 Oct 2003 02:00:10 +0900
thanks for taking the time to put together a detailed response. I
> * 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
> * 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
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
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.