RE: Issue building NAnt
> -Original Message- > From: Curt Arnold [mailto:[EMAIL PROTECTED] > Sent: zaterdag 17 februari 2007 6:20 > To: Gump code and data > Subject: Re: Issue building NAnt > > > On Feb 16, 2007, at 7:09 PM, Curt Arnold wrote: > > However, if you try to do "nant" or "nant test", you will get a > > failure that doesn't support the managed attribute. It > > appears that the build file for NAnt requires features that are not > > in NAnt 0.85. Removing the managed="true" replaces that error with > > another when it tries to run the generated nant.exe as a Mac OS/X > > executable. > > > > > > Changing managed="true" to useruntimeengine="true" will let the units > test pass. I'd suggest using the old name so that you can build the > next release of NAnt with the current release of NAnt and make the > switch after the next release. Basically undo this commit: http:// > nant.cvs.sourceforge.net/nant/nant/NAnt.build?r1=1.236&r2=1.237 I wonder if Ant also does not require to bootstrap the version of Ant that you want to build. I don't think it's necessary to ensure NAnt can be built using a previous release, if such a bootstrap procedure is in place. Nevertheless, I have no problem undoing that commit. It's your call. Gert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue building NAnt
On Feb 16, 2007, at 7:09 PM, Curt Arnold wrote: However, if you try to do "nant" or "nant test", you will get a failure that doesn't support the managed attribute. It appears that the build file for NAnt requires features that are not in NAnt 0.85. Removing the managed="true" replaces that error with another when it tries to run the generated nant.exe as a Mac OS/X executable. Changing managed="true" to useruntimeengine="true" will let the units test pass. I'd suggest using the old name so that you can build the next release of NAnt with the current release of NAnt and make the switch after the next release. Basically undo this commit: http:// nant.cvs.sourceforge.net/nant/nant/NAnt.build?r1=1.236&r2=1.237 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue building NAnt
On Feb 16, 2007, at 6:05 PM, Curt Arnold wrote: 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. I'm a very sick man. Went ahead and installed MonoFramework-1.2.3.1 on Mac OS/X and got NAnt to build but not run self-test, but that should be a start. 1. Download Mono 1.2.3.1_0 Framework - Universal (Stable) from http:// www.mono-project.com/Downloads 2. Install framework 3. Modify /Library/Frameworks/Mono.framework/Versions/1.2.3.1/bin/nant Mono comes with a prebuilt NAnt 0.85, but on Mac OS/X, it needs to have the export PKG_CONFIG_PATH statement added to the nant file. #!/bin/sh export PKG_CONFIG_PATH=/Library/Frameworks/Mono.framework/Versions/ Current/lib/pkgconfig /Library/Frameworks/Mono.framework/Versions/1.2.3.1/lib/ pkgconfig/../../bin/mono /Library/Frameworks/Mono.framework/Versions/ 1.2.3.1/lib/NAnt/NAnt.exe "$@" See http://www.bleepsoft.com/tyler/index.php?itemid=82 and http:// bugzilla.ximian.com/show_bug.cgi?id=79671. Bug should be fixed in next release of Mono. At this point, you should have a usable NAnt 0.85 and all the Mono compilers on the execute path. If you check out NAnt from the source code repository, you can successfully do: nant build However, if you try to do "nant" or "nant test", you will get a failure that doesn't support the managed attribute. It appears that the build file for NAnt requires features that are not in NAnt 0.85. Removing the managed="true" replaces that error with another when it tries to run the generated nant.exe as a Mac OS/X executable. I'd recommend, update Mono on Clarus and changing the NAnt gump descriptor to run "nant build" for now. I'd recommend adding a "gump" target to NAnt.build in the NAnt CVS and then changing the NAnt gump descriptor to run that. NAnt uses log4net which uses NAnt, so we have a little cyclical dependency. Ideally, we would get Gump to build NAnt with its embedded log4net using the framework NAnt, use the built NAnt to build log4net and then build NAnt again using the previously built NAnt and log4net. One step at a time however. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue building NAnt
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
RE: Issue building NAnt
> -Original Message- > From: Curt Arnold [mailto:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. 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). 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue building NAnt
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. I would still be interested in getting the information I requested earlier for the other machine (VMGump). That's right, I have a login for that too: [EMAIL PROTECTED]:~$ pkg-config --modversion mono 1.1.13.2 [EMAIL PROTECTED]:~$ pkg-config --variable=prefix mono /usr/lib/pkgconfig/../.. [EMAIL PROTECTED]:~$ pkg-config --variable=libdir mono /usr/lib/pkgconfig/../../lib [EMAIL PROTECTED]:~$ which mono [EMAIL PROTECTED]:~$ ls -l `pkg-config --variable=prefix mono`/bin/mono ls: /usr/lib/pkgconfig/../../bin/mono: No such file or directory [EMAIL PROTECTED]:~$ ls -l `pkg-config --variable=prefix mono`/lib/mono/1.0 ls: /usr/lib/pkgconfig/../../lib/mono/1.0: No such file or directory /usr/lib/mono also doesn't exist. It seems that we have an incomplete installation on that box. Back to Clarus, I wasn't reading your instructions correctly. The *library* path *does* exist on that box: clarus:~ sctemme$ ls -l `pkg-config --variable=prefix mono`/lib/mono total 0 drwxr-xr-x 134 root wheel 4556 Jan 24 2006 1.0 drwxr-xr-x74 root wheel 2516 Jan 24 2006 2.0 drwxr-xr-x 4 root wheel 136 Jan 24 2006 cocoa-sharp drwxr-xr-x 3 root wheel 102 Jan 24 2006 compat-1.0 drwxr-xr-x 3 root wheel 102 Jan 24 2006 compat-2.0 drwxr-xr-x65 root wheel 2210 Jan 24 2006 gac drwxr-xr-x 3 root wheel 102 Jan 24 2006 monodoc drwxr-xr-x 8 root wheel 272 Jan 24 2006 xbuild Both the 1.0 and 2.0 directories are full of stuff. Clarus and vmgump are getting different errors: http://vmgump.apache.org/gump/public/nant/nant/gump_work/ build_nant_nant.html This one seems to be due to the broken mono install. [EMAIL PROTECTED]:~$ dpkg -l mono Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half- installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- pn mono(no description available) [EMAIL PROTECTED]:~$ Perhaps someone with the necessary Fu on vmgump can run a broom through that? S. -- [EMAIL PROTECTED]http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
RE: Issue building NAnt
> -Original Message- > From: Sander Temme [mailto:[EMAIL PROTECTED] > Sent: vrijdag 16 februari 2007 16:35 > To: Gert Driesen > Cc: 'Gump code and data' > Subject: Re: Issue building NAnt > > > On Feb 15, 2007, at 11:14 PM, Gert Driesen wrote: > > > Is the NAnt build actually failing on that machine, or was the > > build log I > > got from Curt Arnold taken from another machine ? > > The Gump that sends out mail is on another machine (VMGump), but NAnt > is also failing on Clarus: > > http://clarus.apache.org/nant/nant/gump_work/build_nant_nant.html > > > I do not have access to a Mac OS X, so I have not been able to try > > it out > > myself. > > It *should* be the same, right? Since you're running on top of .NET > 'n all. > > Are you Apache committer? If so I can let you on that box. I am, but in this case there isn't much I can do. In NAnt 0.85, we apparently use a method (when targeting .NET 2.0) that was not yet implemented in Mono 1.13.2. 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 would still be interested in getting the information I requested earlier for the other machine (VMGump). Gert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue building NAnt
On Feb 15, 2007, at 11:14 PM, Gert Driesen wrote: Is the NAnt build actually failing on that machine, or was the build log I got from Curt Arnold taken from another machine ? The Gump that sends out mail is on another machine (VMGump), but NAnt is also failing on Clarus: http://clarus.apache.org/nant/nant/gump_work/build_nant_nant.html I do not have access to a Mac OS X, so I have not been able to try it out myself. It *should* be the same, right? Since you're running on top of .NET 'n all. Are you Apache committer? If so I can let you on that box. S. -- [EMAIL PROTECTED]http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
