On Feb 16, 2007, at 3:42 PM, Gert Driesen wrote:
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.
Looking at the message in the Claris log (and not having tried to
build on Mono or checking the Mono revision history), the problem
does not appear to be the compiler, but that the framework is missing
a method that should have been in NET 2.0. The failure message is:
[csc] /Volumes/X1/home/sctemme/work/workspace/nant/
src/NAnt.VSNet/WrapperReferenceBase.cs(358,20): error CS1502: The
best overloaded method match for
`System.Runtime.InteropServices.Marshal.GetTypeLibName
(System.Runtime.InteropServices.UCOMITypeLib)' has some invalid
arguments
[csc] /Volumes/X1/home/sctemme/work/workspace/nant/
src/NAnt.VSNet/WrapperReferenceBase.cs(358,20): error CS1503:
Argument 1: Cannot convert from
`System.Runtime.InteropServices.ComTypes.ITypeLib' to
`System.Runtime.InteropServices.UCOMITypeLib'
[csc] Compilation failed: 2 error(s), 0 warnings
The corresponding code is:
357 #if NET_2_0
358 return Marshal.GetTypeLibName((ITypeLib) typeLib);
359 #else
360 return Marshal.GetTypeLibName((UCOMITypeLib)
typeLib);
361 #endif
The interpretation I have of the failure is that NET_2_0 is true
(hence line 358 appearing in the compiler error), however
Marshal.GetTypeLibName(ITypeLib) which was introduced in .NET 2.0 is
not available in the framework only the obsolete
Marshal.GetTypeLibName(UCOMITypeLib).
Providing a pre-built NAnt is not the ideal solution. It might be
the best possible, but I'm not there yet.
From http://gump.apache.org:
Gump is unique in that it builds and compiles software against the
latest development versions of those projects. This allows gump to
detect potentially incompatible changes to that software just a few
hours after those changes are checked into the version control
system. Notifications are sent to the project team as soon as such
a change is detected, referencing more detailed reports available
online.
A large number of Java projects in Gump are built using Apache Ant.
As Gump builds its projects, it does not use a released version of
Ant but builds it from the current SVN repository. If the Ant
developers mess up something, it could cause 100s of other projects
to fail their build. Eventually, the problem would be traced back to
a modification in the Ant code and the offending code would be
reverted or corrected. Since this is done shortly after the time
that the change was committed and long before people would have
become attached to the new behavior, it should be relatively painless
to correct. If Gump used only released versions of Ant, then a
problem could exist in the Ant SVN for a long time before it was
noticed, additional code might have been written that depended on the
new behavior and it might be very complicated to unwind the problem.
Obviously, there is not the equivalent stack of .NET applications
that depend on NAnt that are built by Gump. But the potential is there.
I have Mac OS/X boxes (both Intel and PowerPC). Have never fired up
Mono on them, but could give it a shot. However it would not be
until Monday. I'll move any more NAnt on Mono discussion to the NAnt-
dev mailing list.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
