Oops, I didn't realize that you needed to be a member to send a message to the
developer list, so I'll try the user list instead...
James.
----- Forwarded message from [EMAIL PROTECTED] -----
Date: Wed, 17 Sep 2003 20:43:09 -0400
From: "James C. Papp" <[EMAIL PROTECTED]>
Subject: "options" for CompilerBase.cs
To: [EMAIL PROTECTED]
How do the NAnt developers feel about adding an �options� property to
CompilerBase.cs? It would work just like the options property in ClTask.cs.
The reason for this is two fold:
1.) It allows access to command line options that are currently not
support by NAnt, and gives future support to new ones without changes to NAnt.
2.) It allows scripts/code/tasks to auto-generate parameters in NAnt
properties and pass them to the compiler.
Also�, I did try to using �arg� properties that are part of any external task;
but they have a few problems.
1.) They do not get included in the compiler response file that NAnt
builds. We have notice that csc.exe does weird things when you have some
options in a response file with others that are not (particularly
with /reference).
2.) They do not allow sophisticated auto-generation of parameters
because
each parameters needs to be a separate xml element. Sometimes the number of
parameters needs is dynamic or not known ahead of time. Being able to pass a
single property for custom options is so convenient.
3.) �arg� does not work with multi-part parameters in an easy way and
by
this I mean parameters like ��file somefile�. It would need to use two
separate �arg� elements because by default, arguments with spaces are quoted
and treated as a single argument.
The code changes to CompilerBase.cs are simple and would look something like
this:
public abstract class CompilerBase : ExternalProgramBase {
�
string _options = null;
�
/// <summary>Optional parameters to pass to compiler.</summary>
[TaskAttribute("options")]
public string Options { get { return _options; } set { _options
= value; }}
�
protected override void ExecuteTask() {
�
if (_options != null)
{
WriteOption(writer, _options);
}
�
}
}
The options parameters should be written right after �addmodule� parameters
are written (this is a change that should also be done for the CLTask.cs as
well) so that you can override NAnt parameters if you need to. For example,
currently in CLTask.cs parameters �/Fd� and �/Fo� are set to the sample output
directory. In are builds we need them to be different. So naturally, we
thought we could use the �options� property to override this behavior but
since �options� are always written first, they can never override parameters
that NAnt uses�
Anyway, this change would simplify our NAnt scripts significantly (we actually
uses a special version of NAnt with this change that we created). So what
does everyone think?
James C. Papp
[EMAIL PROTECTED]
----- End forwarded message -----
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Nant-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-users
