On 2011-08-15, Dominik Psenner wrote: > On 08/15/2011 08:29 AM, Stefan Bodewig wrote: >> Right now the NAnt build builds several different assemblies targeting >> different platforms all out of the same source tree and it should be >> straight forward to extend that to the client profile as well.
>> Tasos' patch basically works the same way as log4net supports the >> compact framework now - it adds a conditional compilation symbol and >> simply excludes all System.Web stuff if that is set. > I get the idea. Until now I didn't understand how log4net was built at > all. If it works, it's fine by me. :-) >> The main hurdle may be NAnt's limited support for .NET 4.0 (need to use >> a nightly build for now) and I don't think there is a target defintion >> for client profiles at all - but that should be doable. I'm willing to >> invest some effort here. > What I've read so far, NAnt 0.91 alpha 2 supports .NET 4.0. At least > that's what they're writing in that table on their frontpage > (http://nant.sourceforge.net/). That's what they say, yes. 8-) > Does that help us? Like I said later, I'm not convinced we need to target 4.0 at all as the 2.0 version should just work. For client profile we could use a stripped down 2.0 version or explicitly target 3.5 (client profile). But I may very well be missing some nuance. >> Longer term switching to MSBuild or the solution task in NAnt and using >> Visual Studio 2010 solution files targeting the correct platform may >> work should we plan to drop support form 1.x, Compact Framework and >> explicit support for Mono. > I would favorise that, but I don't know if that's possible with ASFs > continuous integration. We don't have any (working) CI for log4net right now. The only one I'm aware of is Gump and this one only builds the Mono parts so isn't really useful. It doesn't perform any tests either. Jenkins - one option available from ci.apache.org - does support MSBuild (on Windows, of course) and likely NAnt as well. I know the Lucene.NET project is looking for CI builds so the infrstructure for "real" .NET builds should be there at one point. Stefan
