Re: Issue building NAnt
On Feb 18, 2007, at 9:34 PM, Stefan Bodewig wrote: On Fri, 16 Feb 2007, Gert Driesen [EMAIL PROTECTED] wrote: 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) this would be my preferred option. I don't think I'll find time to do that before the next weekend, though. FWIW I updated Mono on Clarus last night and the NAnt build is now fixed: http://clarus.apache.org/nant/nant/index.html 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
On Fri, 16 Feb 2007, Gert Driesen [EMAIL PROTECTED] wrote: 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) this would be my preferred option. I don't think I'll find time to do that before the next weekend, though. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue building NAnt
On Sat, 17 Feb 2007, Gert Driesen [EMAIL PROTECTED] wrote: I wonder if Ant also does not require to bootstrap the version of Ant that you want to build. Ant bootstraps itself in Gump, yes. It does so using a shell script that is part of the distribution. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue building NAnt
- Original Message - From: Stefan Bodewig [EMAIL PROTECTED] To: general@gump.apache.org Sent: Monday, February 19, 2007 6:36 AM Subject: Re: Issue building NAnt On Sat, 17 Feb 2007, Gert Driesen [EMAIL PROTECTED] wrote: I wonder if Ant also does not require to bootstrap the version of Ant that you want to build. Ant bootstraps itself in Gump, yes. It does so using a shell script that is part of the distribution. We ship with a small shell script for bootstrapping as well. 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
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 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
-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 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
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 exec 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.236r2=1.237 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 exec 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.236r2=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 15, 2007, at 12:47 AM, Gert Driesen wrote: Would it possible to send me the output of the following commands on the gump machine: $ pkg-config --modversion mono $ pkg-config --variable=prefix mono $ pkg-config --variable=libdir mono $ which mono On clarus.apache.org. (an Xserve running Mac OS X Server 10.4.8, and Gump): clarus:~ sctemme$ pkg-config --modversion mono 1.1.13.2 clarus:~ sctemme$ pkg-config --variable=prefix mono /Library/Frameworks/Mono.framework/Versions/1.1.13.2/lib/pkgconfig/../.. clarus:~ sctemme$ pkg-config --variable=libdir mono /Library/Frameworks/Mono.framework/Versions/1.1.13.2/lib/ pkgconfig/../../lib clarus:~ sctemme$ which mono /usr/bin/mono clarus:~ sctemme$ ls -l /usr/bin/mono lrwxr-xr-x 1 root wheel 48 Feb 18 2006 /usr/bin/mono - /Library/ Frameworks/Mono.framework/Commands/mono Can you also verify whether the following files/directories exist: $prefix/bin/mono clarus:~ sctemme$ ls -l `pkg-config --variable=prefix mono`/bin/mono -rwxr-xr-x 1 root wheel 4539848 Jan 24 2006 /Library/Frameworks/ Mono.framework/Versions/1.1.13.2/lib/pkgconfig/../../bin/mono $prefix/lib/mono/1.0 = this probably won't exist The above is a regular file so, no. If there is anything else I can do to help, please let me know. 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 7:45 To: Gump code and data; Gert Driesen Subject: Re: Issue building NAnt On Feb 15, 2007, at 12:47 AM, Gert Driesen wrote: Would it possible to send me the output of the following commands on the gump machine: $ pkg-config --modversion mono $ pkg-config --variable=prefix mono $ pkg-config --variable=libdir mono $ which mono On clarus.apache.org. (an Xserve running Mac OS X Server 10.4.8, and Gump): clarus:~ sctemme$ pkg-config --modversion mono 1.1.13.2 clarus:~ sctemme$ pkg-config --variable=prefix mono /Library/Frameworks/Mono.framework/Versions/1.1.13.2/lib/pkgconfig/../. . clarus:~ sctemme$ pkg-config --variable=libdir mono /Library/Frameworks/Mono.framework/Versions/1.1.13.2/lib/ pkgconfig/../../lib clarus:~ sctemme$ which mono /usr/bin/mono clarus:~ sctemme$ ls -l /usr/bin/mono lrwxr-xr-x 1 root wheel 48 Feb 18 2006 /usr/bin/mono - /Library/ Frameworks/Mono.framework/Commands/mono Can you also verify whether the following files/directories exist: $prefix/bin/mono clarus:~ sctemme$ ls -l `pkg-config --variable=prefix mono`/bin/mono -rwxr-xr-x 1 root wheel 4539848 Jan 24 2006 /Library/Frameworks/ Mono.framework/Versions/1.1.13.2/lib/pkgconfig/../../bin/mono $prefix/lib/mono/1.0 = this probably won't exist The above is a regular file so, no. If there is anything else I can do to help, please let me know. Is the NAnt build actually failing on that machine, or was the build log I got from Curt Arnold taken from another machine ? I do not have access to a Mac OS X, so I have not been able to try it out myself. Gert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
