RE: [nant-dev] NAnt and Gump -- getting closer...
Clayton was wondering if we could use References inside NAnt, and
Gump write a pre-defined include file [it does something
similar when
it run Maven]. Does this idea have legs? Will it work for
compiles and
tests?
I don't think it would work for tests. Can you specify the
path to nunit.core.dll at runtime for NAnt's nunit task -
or maybe before runtime, but to a value that may be different
every day?
Hi, sorry I am ringing in so late it has been a long day. Adam I think
we were talking more or less about the include file that could be used
to override a path in a build file (i.e. a lib directory). So the
referencing file/ build master file would look something like this:
include buildfile=my.local.xml failonerror=false/
csc target=exe output=HelloWorld.exe debug=true
nowarn
!-- do not report warnings for missing XML
comments --
warning number=0519 /
/nowarn
sources
include name=**/*.cs /
/sources
resources dynamicprefix=true prefix=HelloWorld
include name=**/*.resx /
/resources
references
include name=${lib.dir}/MyLibrary.dll/
include name=System.dll /
include name=System.Data.dll /
/references
/csc
And then in your local copy of gump you would override lib.dir:
property name=lib.dir value=/my/new/lib/dir
readonly=true/
Applying this to the NAnt.build file would give you the ability to point
at a different bin folder (pseudo build file):
!-- in include file --
property name=lib.dir value=/my/root/lib/dir/
property name=lib.family.dir
value=${path::combine(lib.root, lib.family.dir)} readonly=true/
!-- and in NAnt.build this line would now point at your new lib root
path
if the include was added to the build script
--
property name=lib.framework.dir
value=${path::combine(lib.family.dir,
framework::get-version(framework::get-target-framework()))}
dynamic=true /
It would not allow you to change the nunit/ binary at runtime though
but you could recompile with a freshly built bin dependancy tree...which
would in effect allow you to run with a different version of nunit.
It is late so I hope that makes sense :-).
Cheers,
Clayton
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47alloc_id808op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NAnt and Gump -- getting closer...
On Tue, 7 Sep 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: I think the answer is 'who decides what is the right approach', and I feel it is the NAnt team. Yes, I agree. We may need to explain in more detail what we want to do and why we want to do that with Gump, but we need the expertize of the NAnt folks to achieve that. I'd like to have the nant.xml metadata describe a bootstrap-nant project (maybe we call it mini-nant) that calls the script (that uses mini-NAnt to build NAnt.exe, wherever that is) and then we use that to build the next projects. The script would need to know which framework you intend to use. For the Bourne shell script this simply means something like #!/bin/sh mono bin/NAnt.exe (ignoring Rotor and DotGNU for now) but the Windows batch file is a different beast. If there really is no purpose for a script I could add an exe element to Gump, but that worries me (only a little). Again, you'd need to handle it differently when running Mono (you don't invoke the executable directly). As for the GAC, and the DEVPATH environment variable, we don't have a perfect answer yet -- do we? No, I don't think we have. Since we control the machine running Gump we can ensure that the GAC is more or less empty. After that we may get away with the dump everything into a single directory strategy. Clayton was wondering if we could use References inside NAnt, and Gump write a pre-defined include file [it does something similar when it run Maven]. Does this idea have legs? Will it work for compiles and tests? I don't think it would work for tests. Can you specify the path to nunit.core.dll at runtime for NAnt's nunit task - or maybe before runtime, but to a value that may be different every day? As for output -- it exists (as do artifact and jar) and ought work. Artifact and Jar are simply aliases (right now) with no extra meaning. What types were you thinking of Stefan? type=library and|or executable or something? type=jar|license|library|executable|documentation|... As for language=csharp, if there truly is no significant difference between the various languages, I am more than game to do platform=dotnet|java. I think this would be the correct approach. BTW: Ought we attempt to contribute metadata for the mini-nant up to nant projects (including log4net, etc.) and see if we can get that working from within Gump? I think that makes a good first goal. I don't understand that, sorry. Are you asking whether we should try log4net first once we manage to use NAnt from within Gump? Yes, it looks like a good candidate. As would NUnit. Stefan --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NAnt and Gump -- getting closer...
BTW: Ought we attempt to contribute metadata for the mini-nant up to nant projects (including log4net, etc.) and see if we can get that working from within Gump? I think that makes a good first goal. I don't understand that, sorry. Are you asking whether we should try log4net first once we manage to use NAnt from within Gump? Yes, it looks like a good candidate. As would NUnit. When working with Clayton on Saturday we had NAnt being called by Gump (on it's own source), but that was a simple invocation (with NAnt expected to be on the path). The work for calculating a DEVPATH is in there, but untested in that simple scenario. Take a peek at gump-n.xml (workspace and profile) for this. Above I was discussing trying to set up the mini-nant (ala bootstrap-ant) to nant (ala ant) metadata, i.e. all the projects that are in this work list that Jaraslow (aka Jarek) wrote: --- Jarek wrote: BTW. I've been thinking about it for a while and the process of fully rebuilding NAnt is quite complicated: 1. Download NAnt sources from CVS 2. Bootstrap NAnt using mini-nant and binary libraries found in CVS (bin/lib directory) 3. From now on, use the bootstrapped NAnt 4. Download and rebuild the platform-neutral version of log4net.dll 5. Download and rebuild the platform-specific version of NUnit.*.dll 6. Download and rebuild the platform-specific version of NDoc.*.dll 7. Download and rebuild the ICSharpCode.SharpCvsLib.Console.dll referencing the log4net.dll built in step 4 8. Download and rebuild the ICSharpCode.SharpZip.dll 9. Put the just-built DLLs in the appropriate nant/bin/lib subdirectory 11. Bootstrap NAnt again by using the previously built nant (not the mini-nant) and the fresh libraries --- If we can square away this set of projects, and get this behaviour correct, and then (for projects that depends upon project==nant) use the output from 11, then I feel we've achieved a good enough/tested enough base. regards, Adam --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NAnt and Gump -- getting closer...
The script would need to know which framework you intend to use. For the Bourne shell script this simply means something like #!/bin/sh mono bin/NAnt.exe (ignoring Rotor and DotGNU for now) but the Windows batch file is a different beast. We could set a Gump parameter in the workspace and launch nant-%FRAMEWORK%.[sh|bat] as the script, meaning a different one per framework. Alternatively we could pass the framework as a parameter. Whichever works best for the NAnt community... regards Adam --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NAnt and Gump -- getting closer...
I don't know exactly what you're trying to achieve with Gump, but IMO things are much easier than you think if you fully utilize NAnt's potential. Nant is quite a portable beast today. It can run on 4 platforms (mono-1.0, net-1.0, net-1.1, net-2.0) and compile for some more (netcf-1.0 and sscli). The platform of your choice influences all .NET tasks and involves platform-specific lookup and commandline parameter pasing. Many things have been done to assure platform independence so that you can run target multiple platforms with little to no change in your build scripts. NAnt provides all the logic to detect the presence and location of platform-specific assemblies and to pass them as arguments to appropriate commandline compilers. On windows it's possible to target all the platforms (including mono for windows). On Linux it's only possible to target mono-1.0. To compile for a particular platform you simply run nant.exe -targetframework:net-1.0 buildfile.build nant.exe -targetframework:net-1.1 buildfile.build nant.exe -targetframework:net-2.0 buildfile.build nant.exe -targetframework:mono-1.0 buildfile.build nant.exe -targetframework:netcf-1.0 buildfile.build If you don't provide the target platform it's assumed that you want to target the current platform you're running on (.NET 1.1 in most cases, but can be .NET 2.0 or .NET 1.0). Nant can be run from any directory, there's no need to invoke it in the build file directory. The sequence used to download, compile and install nant from CVS is very simple: cvs checkout nant nant\bin\NAnt.exe install -f:nant\NAnt.build -D:install.prefix=targetprefix I believe that all steps necessary to fully bootstrap nant from source (including external dependencies) can be easily put in a single build file that would be invoked by just-bootstrapped nant itself. The build would be very simple and would just consist of cvs-checkout, nant and copy tasks. Or perhaps I am missing something... Correct me if I'm wrong. Jarek BTW. You may contact me on ICQ #298783166 or somewhere on IRC - Original Message - From: Adam R. B. Jack [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Stefan Bodewig [EMAIL PROTECTED] Sent: Tuesday, September 07, 2004 6:37 PM Subject: Re: [nant-dev] NAnt and Gump -- getting closer... The script would need to know which framework you intend to use. For the Bourne shell script this simply means something like #!/bin/sh mono bin/NAnt.exe (ignoring Rotor and DotGNU for now) but the Windows batch file is a different beast. We could set a Gump parameter in the workspace and launch nant-%FRAMEWORK%.[sh|bat] as the script, meaning a different one per framework. Alternatively we could pass the framework as a parameter. Whichever works best for the NAnt community... regards Adam --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NAnt and Gump -- getting closer...
I don't know exactly what you're trying to achieve with Gump, but IMO things are much easier than you think if you fully utilize NAnt's potential. Yeah, I think we need to step back and make that clear. Gump is attempting to emulate a rabid OSS developer, perform the steps a developer would do in order to download and build NAnt, and then others -- from scratch. This OSS developer is particulary anal, they don't want yesterdays build ... they want it fresh, everything the very latest. Their objective isn't to run this, it is to monitor for changes, disconnects. If project X breaks project Y the developer wishes to feel this pain. This automated developer is there to reduce pain for human developers/users, and to catch interface change pain early! If early enough perhaps the problem can be resolved before a release is made, and a problems gets into the field. Gump is a Python program that interacts with things (CVS, SVN, Shell, Ant, Maven) and we'd like NAnt. Gump wants to bootstrap NAnt 'cos it was to also catch NAnt changes --- not just compilation, but runtime. Being an outsider is important. Gump is Python (not Java) so it is spearate from concerns of the platform, and this ought make it a good candidate for working on DotNet. We want to work with NAnt as NAnt ought be worked with, but not inside NAnt, outside -- as a developer would be. Further, we want to allow existing NAnt scripts -- as they exist today -- without change. This allows projects to benefit from Gump without changing how they work. At least, that is what we'd like. For more/historical information see: http://gump.apache.org/why.html regards, Adam --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
