Mailing-List: contact general-help@gump.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Gump code and data" <general@gump.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
From: "Gert Driesen" <gert.driesen@telenet.be>
To: "'Gump code and data'" <general@gump.apache.org>
References: <00d701c750dd$ea1cf7f0$d9071fac@ardatis.local>
 <AF7E41B3-12E8-4E80-8F78-B14E1EBF08C2@apache.org>
 <004601c7519a$26aaf520$7400df60$%driesen@telenet.be>
 <9DEBD641-8535-4BAE-8A2E-AF0F68B8E6BB@apache.org>
 <00e201c751e1$af5b5bc0$0e121340$%driesen@telenet.be>
 <9DF6E4A7-49CA-4B11-9E99-8059DDAB7D09@apache.org>
 <DE3A1C71-B870-4451-9350-7490965BFCD7@apache.org>
In-Reply-To: <DE3A1C71-B870-4451-9350-7490965BFCD7@apache.org>
Subject: RE: Issue building NAnt
Date: Fri, 16 Feb 2007 22:42:14 +0100
Message-ID: <012801c75213$52e16d30$f8a44790$@driesen@telenet.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcdSDKhMpo3yrMMRQ6qMvyo0LKPjjgAAZa+Q
Content-Language: nl-be


> -----Original Message-----
> From: Curt Arnold [mailto:carnold@apache.org]
> Sent: vrijdag 16 februari 2007 21:54
> To: Gump code and data
> Subject: Re: Issue building NAnt
> 
> 
> On Feb 16, 2007, at 10:30 AM, Sander Temme wrote:
> 
> >
> > On Feb 16, 2007, at 7:46 AM, Gert Driesen wrote:
> >
> >> You either need a more recent version of Mono, or I could modify
> >> NAnt to
> >> allow it to compile on that version of Mono. I don't know if you'd
> >> consider
> >> using a nightly build (or any non-released version) of NAnt.
> >
> > I'll look into upgrading Mono on Clarus.  Using nightly builds is
> > not what Gump is about: it merely tries to compile the latest,
> > perhaps-not-so-greatest of everything, satisfying dependencies with
> > the development trunk of that moment.  It uses that to find out
> > when/where things break at the earliest possible moment.
> >
> 
> Looking at the code that fails on Mono, it looks like the problem is
> that Mono is detected as supporting .NET 2 but is missing a framework
> method expected to be there.

NAnt by default targets that CLR on which its running, and it by default
runs on the latest supported CLR.

Hence on a system containing both the 1.0 and 2.0 profile of Mono, NAnt is
built targeting Mono 2.0.

Note: you can of course still build application targeting Mono 1.0 using a
version of NAnt that was built for Mono 2.0.

> I'm guessing that it would either
> successfully compile on something earlier that was not detected
> as .NET 2 or something later that had the missing method.  Do you
> know of a later version of Mono that NAnt does build on?  Updating
> the Mono version seems to be the right direction as I'm guessing .NET
> 1 is slowly fading (though I'm not in that world very much).

Problem is that Mono's C# compiler has become more (and in some cases too)
strict.

Since we always compile NAnt with /warnaserror (to ensure we have clean
code), you'll also get a build failure with the 0.85 release on very recent
versions of Mono.  The "issue" that the newer compiler reports is fixed in
CVS though.

I'm not sure what the best way of fixing this is. I was considering
releasing a new (beta) version of NAnt anyway, but then again I think you
guys want official releases only.

So either:

* you update Mono to a release that does not yet contain this extra strict
compiler behavior (1.2.0 or 1.2.1 should be ok)
* I provide you with a build script patch that causes the /warnaserror
option not be set
* I release a new (beta) version of NAnt for you to use

I wish there were other (better) options, but I can't think of any right
now.  Perhaps we should stop treating warnings as error when compiling NAnt.
It keeps code clean, but also leads to issues like this one here.

> As for vmgump, previous statements suggest it is pretty precarious
> and I doubt that the benefit would be worth the risk to touch Mono on
> it until the next major externally driven change.  For log4net, as
> long as we had NAnt and log4net building on Claris and ideally with
> nag messages sent to the appropriate mailing lists, things would be
> good.

Sounds like a plan.

Gert


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org