зеркало из https://github.com/mono/mail-archives.git
179 строки
7.3 KiB
HTML
179 строки
7.3 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE> [Mono-list] Mono Tools and Utilities
|
|
</TITLE>
|
|
<LINK REL="Index" HREF="index.html" >
|
|
<LINK REL="made" HREF="mailto:ianm%40ActiveState.com">
|
|
<META NAME="robots" CONTENT="index,nofollow">
|
|
|
|
<LINK REL="Previous" HREF="016334.html">
|
|
<LINK REL="Next" HREF="016368.html">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#ffffff">
|
|
<H1>[Mono-list] Mono Tools and Utilities
|
|
</H1>
|
|
<B>Ian MacLean
|
|
</B>
|
|
<A HREF="mailto:ianm%40ActiveState.com"
|
|
TITLE="[Mono-list] Mono Tools and Utilities">ianm@ActiveState.com
|
|
</A><BR>
|
|
<I>Tue, 14 Oct 2003 02:00:10 +0900</I>
|
|
<P><UL>
|
|
<LI> Previous message: <A HREF="016334.html">[Mono-list] Mono Tools and Utilities
|
|
</A></li>
|
|
<LI> Next message: <A HREF="016368.html">[Mono-list] Mono Tools and Utilities
|
|
</A></li>
|
|
<LI> <B>Messages sorted by:</B>
|
|
<a href="date.html#16347">[ date ]</a>
|
|
<a href="thread.html#16347">[ thread ]</a>
|
|
<a href="subject.html#16347">[ subject ]</a>
|
|
<a href="author.html#16347">[ author ]</a>
|
|
</LI>
|
|
</UL>
|
|
<HR>
|
|
<!--beginarticle-->
|
|
<PRE>Peter,
|
|
thanks for taking the time to put together a detailed response. I
|
|
appreciate it.
|
|
|
|
><i> * Using XML to express the build rules is, IMO, too heavyweight.
|
|
</I>><i> I can see how it's easy to parse and gives an easy mechanism
|
|
</I>><i> for interfacing with tasks, but writing a build file is like
|
|
</I>><i> programming in any other language; it's better to have the
|
|
</I>><i> common bits easy and the rare bits hard than everything
|
|
</I>><i> somewhere in an awkward medium.
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>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.
|
|
|
|
><i> * The replacement of shell commands with tasks is important, of
|
|
</I>><i>course, but the commands still seem on the low-level side
|
|
</I>><i> of things: copy file, delete file, compile to this file; what
|
|
</I>><i> happens if I'm compiling foo.so on Linux and foo.dll on
|
|
</I>><i> Windows?
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>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> * I haven't seen indications that it's particularly aware of
|
|
</I>><i> recursion.
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>Could you elaborate on what recursion awareness means in this context ?
|
|
|
|
><i> * It looks like you can implement tasks in user assemblies but I
|
|
</I>><i> don't see a framework for distributing them sanely (which
|
|
</I>><i> I believe to be very important: aclocal, anyone?)
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>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 ?
|
|
|
|
><i> * Similarly, it doesn't look like you can define tasks in the
|
|
</I>><i> XML itself.
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>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> * You still have to write your own clean rules and dist rules.
|
|
</I>><i> Surely the tool, knowing the targets and all the rules used
|
|
</I>><i> to build them, could figure this out by itself?
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>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.
|
|
|
|
><i> * Still using file modtimes, not MD5 sums, as criteria for
|
|
</I>><i> rebuilding. Not the end of the world, but if you change a
|
|
</I>><i> comment in a C file and have to relink your executable
|
|
</I>><i> as a result, it can be a drag.
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>hmm - I've used other build tools - cons ( <A HREF="http://www.dsmit.com/cons/">http://www.dsmit.com/cons/</A>)
|
|
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> * Judging from idea of build properties, configuration state
|
|
</I>><i> is still kept outside of the build tool.
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>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.
|
|
|
|
><i>NAnt seems to improve on the implementation of make while still working
|
|
</I>><i>within the same basic framework. My opinion is that there's a lot to be
|
|
</I>><i>gained from really rethinking what it means to "build" something and
|
|
</I>><i>structuring the process a lot more.
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>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>To try to articulate that idea a bit more, here's a quote from the NAnt
|
|
</I>><i>webpage that struck me:
|
|
</I>><i>
|
|
</I>><i> Important: Some tasks like the compiler tasks will only execute
|
|
</I>><i> if the date stamp of the generated file is older than the source
|
|
</I>><i> files. If you compile HelloWorld project in debug mode and then
|
|
</I>><i> try to compile it again in non-debug mode without first cleaning
|
|
</I>><i> nothing will happen because NAnt will think the project does not
|
|
</I>><i> need rebuilding.
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>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
|
|
|
|
|
|
|
|
|
|
</PRE>
|
|
<!--endarticle-->
|
|
<HR>
|
|
<P><UL>
|
|
<!--threads-->
|
|
<LI> Previous message: <A HREF="016334.html">[Mono-list] Mono Tools and Utilities
|
|
</A></li>
|
|
<LI> Next message: <A HREF="016368.html">[Mono-list] Mono Tools and Utilities
|
|
</A></li>
|
|
<LI> <B>Messages sorted by:</B>
|
|
<a href="date.html#16347">[ date ]</a>
|
|
<a href="thread.html#16347">[ thread ]</a>
|
|
<a href="subject.html#16347">[ subject ]</a>
|
|
<a href="author.html#16347">[ author ]</a>
|
|
</LI>
|
|
</UL>
|
|
</body></html>
|