зеркало из https://github.com/mono/mail-archives.git
149 строки
5.9 KiB
HTML
149 строки
5.9 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:jonpryor%40vt.edu">
|
|
<META NAME="robots" CONTENT="index,nofollow">
|
|
|
|
<LINK REL="Previous" HREF="016321.html">
|
|
<LINK REL="Next" HREF="016324.html">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#ffffff">
|
|
<H1>[Mono-list] Mono Tools and Utilities
|
|
</H1>
|
|
<B>Jonathan Pryor
|
|
</B>
|
|
<A HREF="mailto:jonpryor%40vt.edu"
|
|
TITLE="[Mono-list] Mono Tools and Utilities">jonpryor@vt.edu
|
|
</A><BR>
|
|
<I>Sun, 12 Oct 2003 15:44:28 -0400</I>
|
|
<P><UL>
|
|
<LI> Previous message: <A HREF="016321.html">[Mono-list] Mono Tools and Utilities
|
|
</A></li>
|
|
<LI> Next message: <A HREF="016324.html">[Mono-list] Mono Tools and Utilities
|
|
</A></li>
|
|
<LI> <B>Messages sorted by:</B>
|
|
<a href="date.html#16322">[ date ]</a>
|
|
<a href="thread.html#16322">[ thread ]</a>
|
|
<a href="subject.html#16322">[ subject ]</a>
|
|
<a href="author.html#16322">[ author ]</a>
|
|
</LI>
|
|
</UL>
|
|
<HR>
|
|
<!--beginarticle-->
|
|
<PRE>I'm not sure that autoconf/automake is a good match for C#.
|
|
|
|
Though if we went that route, supporting "make distcheck" would become
|
|
trivial. ;-) (Ignore this unless you read cvs-list...)
|
|
|
|
I'm primarily after something that would be fairly easy to support. I
|
|
need to minimize the work required on my part, as I only have a few
|
|
hours a week, and most of that goes toward email. This is likely true
|
|
for many people.
|
|
|
|
So there are five possible build systems I see that could be used for
|
|
mono-tools:
|
|
|
|
1. autoconf/automake: usable, but likely more complicated than
|
|
it needs to be.
|
|
|
|
However, if we want to add a lot of code that already makes
|
|
use of autoconf/automake, it may be sensible to just make
|
|
everything use autoconf/automake. (There is already support
|
|
in mono-tools to support a hybrid autoconf & Makefile
|
|
system.)
|
|
|
|
2. NAnt: It exists, and people are familiar with it, but little
|
|
(if any) of the existing Mono code uses it.
|
|
|
|
Furthermore, with the performance issues that were noted
|
|
last week, it's not an ideal solution now. That may change
|
|
soon, though.
|
|
|
|
3. New build tool: Might be nice, but no one has time to work
|
|
on such a thing right now. Probably not worth waiting for.
|
|
|
|
4. Use the existing mcs/build scripts: This was my initial
|
|
idea.
|
|
|
|
Pros: it exists and works. Cons: Might be too complicated
|
|
for long term support.
|
|
|
|
5. Write a new set of Makefiles: Requires writing new scripts.
|
|
|
|
At present a mix of (1) and (5) is in use (autoconf is used, and will
|
|
search subdirectories for configure scripts to run at configure time,
|
|
and type-reflector has it's own Makefile system).
|
|
|
|
Furthermore, following (4) would allow programs already in mcs/tools
|
|
(such as SqlSharp and security/certview) to be moved with minimal/no
|
|
changes to their Makefiles.
|
|
|
|
The question is, what should be adopted for long-term development use.
|
|
|
|
Suggestions? Opinions?
|
|
|
|
- Jon
|
|
|
|
On Sun, 2003-10-12 at 15:15, Peter Williams wrote:
|
|
><i> Hi Jon,
|
|
</I>><i>
|
|
</I>><i> On Sun, 2003-10-12 at 10:59, Jonathan Pryor wrote:
|
|
</I>><i> > So I would also propose the following:
|
|
</I>><i> >
|
|
</I>><i> > 1. Move mcs/build into a new CVS repository, "build"
|
|
</I>><i> > 2. Use the CVS aliasing functionality [1] to insert the "build"
|
|
</I>><i> > CVS repository into the "mcs" and "mono-tools" repositories.
|
|
</I>><i> > This would allow the build system to be located in one
|
|
</I>><i> > location, and all users would receive updates
|
|
</I>><i> > simultaneously.
|
|
</I>><i>
|
|
</I>><i> As the guy who wrote most of the build system, I'm not sure if this is
|
|
</I>><i> the best idea, although the build system is so low-maintenance that I
|
|
</I>><i> don't think moving it would be a huge problem. My reasons are:
|
|
</I>><i>
|
|
</I>><i> * A lot of the build system is about supporting *complex*
|
|
</I>><i> cross-platform compilations: of corlib, with large source
|
|
</I>><i> trees, with interdependent libraries, etc. I suspect
|
|
</I>><i> mono-tools' needs would be simpler, and could probably be
|
|
</I>><i> met with a much smaller set of Makefile code
|
|
</I>><i>
|
|
</I>><i> * Trying to implement a nontrivial build with make is just so
|
|
</I>><i> much more of a hassle than it should be. On the other hand,
|
|
</I>><i> I think nant has many bad design decisions, and although I
|
|
</I>><i> have an (IMHO) awesome idea and basic framework for a C#
|
|
</I>><i> build tool, I (of course) have ~0 free time to work on it.
|
|
</I>><i>
|
|
</I>><i> * This is relatively minor, but if more projects start using
|
|
</I>><i> the build/ files, then they *will* become high maintenance,
|
|
</I>><i> and if people are going to spend time on a build system, I'd
|
|
</I>><i> much rather it be on implementing a better one, rather than
|
|
</I>><i> working within the confines of pure make.
|
|
</I>><i>
|
|
</I>><i> Anyway, if you want to alias the build/ stuff, I'm not against it, I'm
|
|
</I>><i> just not totally encouraging it. My feeling is it might be easiest and
|
|
</I>><i> sanest just to bolt into autoconf/automake as best you can.
|
|
</I>><i>
|
|
</I>><i> Peter
|
|
</I>
|
|
|
|
</PRE>
|
|
<!--endarticle-->
|
|
<HR>
|
|
<P><UL>
|
|
<!--threads-->
|
|
<LI> Previous message: <A HREF="016321.html">[Mono-list] Mono Tools and Utilities
|
|
</A></li>
|
|
<LI> Next message: <A HREF="016324.html">[Mono-list] Mono Tools and Utilities
|
|
</A></li>
|
|
<LI> <B>Messages sorted by:</B>
|
|
<a href="date.html#16322">[ date ]</a>
|
|
<a href="thread.html#16322">[ thread ]</a>
|
|
<a href="subject.html#16322">[ subject ]</a>
|
|
<a href="author.html#16322">[ author ]</a>
|
|
</LI>
|
|
</UL>
|
|
</body></html>
|