Sorry if this message was sent twice. I did not realize I needed to be a
subscriber to post a message to the list. So let’s see if this gets through
now that I am.
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) {
writer.WriteLine(“{0}”, _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]
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
