Re: [nant-dev] DependsTask Patch (fix)
I've finally made it into the office today and was able to test out the quick
changes I made. I fixed a missing attribute and missing #endregion directive
(this is the version without the dynamic attribute).
BTW, thanks for taking the time to looks at this stuff - I really appreciate it.
James.
Quoting Scott Hernandez [EMAIL PROTECTED]:
I'm inclined to put new tasks like this in NAntContrib. Does anyone have a
major complaint about that? We can always move it later.
As for your implementation; It seems okay. I'm a little confused about what
you've done for the on attribute. It looks like you are not expanding,
supporting expressions, for those values unless an additional attribute
dynamic is set. What is the value in this?
It would seem cleaner to me to just let the on attribute be auto-expanded.
- Original Message -
From: James C. Papp [EMAIL PROTECTED]
DependsTask Patch
Here is an implementation of the depends/ task. It allows the use of
dynamic
dependencies which was possible with earlier versions of NAnt through the
call/ task, but with current changes is now longer allowed (deprecation
of
the force attribute).
It is particularly useful for handling dependencies that change based on
some
input conditions/parameters, or when the dependencies are not known until
runtime.
Here's a quick example of the possibilities:
target name=foo
if test=${some-option}
depends on=A, B, ${set-at-runtime-target}/
/if
/target
For more information about this, check out the thread: [nant-dev] Change
to
call task makes upgrade difficult
http://www.mail-archive.com/nant-developers%40lists.sourceforge.net/msg03105.html
Personally, I think it should be part of the core because it really is an
expansion of the target/ depends attribute (they go hand-in-hand),
however; I
would be just as happy if everyone decided to stick it in NAntContrib.
DependsTask.zip
Description: Zip compressed data
Re: [nant-dev] DependsTask Patch
The dynamic attribute is set to true by default, so normally you would not have
to touch it, though I agree with you, I don't see any reason why you would ever
want to prevent the expansion of the on attribute. It was a leftover from my
testing harness and I just never removed it. I've included a new patch with
the dynamic attribute removed.
Let me know if you want any other changes. Just so you know, I'm currently
snowed in and consequently not at the office, so I couldn't verify my snips, so
hopefully it still compiles.
James.
Quoting Scott Hernandez [EMAIL PROTECTED]:
I'm inclined to put new tasks like this in NAntContrib. Does anyone have a
major complaint about that? We can always move it later.
As for your implementation; It seems okay. I'm a little confused about what
you've done for the on attribute. It looks like you are not expanding,
supporting expressions, for those values unless an additional attribute
dynamic is set. What is the value in this?
It would seem cleaner to me to just let the on attribute be auto-expanded.
- Original Message -
From: James C. Papp [EMAIL PROTECTED]
DependsTask Patch
Here is an implementation of the depends/ task. It allows the use of
dynamic
dependencies which was possible with earlier versions of NAnt through the
call/ task, but with current changes is now longer allowed (deprecation
of
the force attribute).
It is particularly useful for handling dependencies that change based on
some
input conditions/parameters, or when the dependencies are not known until
runtime.
Here's a quick example of the possibilities:
target name=foo
if test=${some-option}
depends on=A, B, ${set-at-runtime-target}/
/if
/target
For more information about this, check out the thread: [nant-dev] Change
to
call task makes upgrade difficult
http://www.mail-archive.com/nant-developers%40lists.sourceforge.net/msg03105.html
Personally, I think it should be part of the core because it really is an
expansion of the target/ depends attribute (they go hand-in-hand),
however; I
would be just as happy if everyone decided to stick it in NAntContrib.
DependsTask.zip
Description: Zip compressed data
Re: [nant-dev] Patch for resultproperty and outputproperty attributes for exec/
Yea, I was thinking the same thing (Ant does it this way), but sometimes you want the combined output (particularly with Windows command-line tools which seem not to get the whole stderr, stdout concept), and if you have two separate properties there is no way to recombined them in the order that the data was received. What if I add a new attribute called outputpropertymode which could be set to stderr, stdout, or alloutput (with the default set to alloutput). The names are open to suggestions. Just let me know and I'll make the changes. Thanks, James Quoting Ian MacLean [EMAIL PROTECTED]: James, This looks good. However I'm wondering if it would be better to use seperate properties for stderr and stdout Ian Here is a patch that adds two badly needed features (well..., at least for me :-)) to the exec/ task. One is resultproperty, which is used to specify a property that will receive the exit code of the process (it more useful when failonerror is false). The other one is outputproperty, which is used to specify a property that will receive the output of the process. Unlike Ant, this includes both the standard and error streams and works regardless if the output has been redirected to a file. This is very handy for programs like perforce were the output of the command is needed to determine build events later on in the script. The data return for both properties is always that last execution of the process (for example, if you use retrycount). James. -- Ian MacLean, Developer, ActiveState, a division of Sophos http://www.ActiveState.com --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Patch for resultproperty and outputproperty attributes for exec/
Here is a patch that adds two badly needed features (well..., at least for me :-)) to the exec/ task. One is resultproperty, which is used to specify a property that will receive the exit code of the process (it more useful when failonerror is false). The other one is outputproperty, which is used to specify a property that will receive the output of the process. Unlike Ant, this includes both the standard and error streams and works regardless if the output has been redirected to a file. This is very handy for programs like perforce were the output of the command is needed to determine build events later on in the script. The data return for both properties is always that last execution of the process (for example, if you use retrycount). James. ExternalProgramBase.zip Description: Zip compressed data
[nant-dev] Patches
Just in case the attachments for the two patches I just submitted did not make it to the list, they are also available from the sourceforge Patches feature accessible from the main page. http://sourceforge.net/tracker/?group_id=31650atid=402870 James. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Change to call task makes upgrade difficult
Well, reintroducing the force attribute seems like a bad idea since it has
already been deprecated (but thanks for asking); its resurrection would
probably just cause too much confusion.
Your solution:
call target=foo unless=target::has-executed('foo')/
(BTW, all the new expression evaluation and function support is awesome. With
these new capabilities I can finally remove a bunch of custom C#
script-functions in our NAnt build files. Though, the fact that we could do
something as shown above is just too cool...)
Anyway, back to your solution. This may work, but it all depends on how the
call task handles dependencies; here's an example:
target name=A depends=B, C/
target name=B depends=D, F/
target name=C depends=D, E/
target name=D/
target name=E /
target name=F /
Let's say that task A is triggered (via a call task, or something equivalent
like the proposed depends tasks). There are five possible ways things can
occur (unfortunately):
1. Task A executes regardless if it executed before and dependencies are
ignored.
= A
2. Task A executes but only if it has not so far; dependencies are ignored.
= (A)
3. Task A executes regardless if it executed before and all its dependencies
are force to execute as well (even duplicates)
= D, F, B, D, E, C, A
4. Task A executes regardless if it executed before as well as all its
dependencies but duplicates are prevented from executing more then once.
= D, F, B, E, C, A
5. Task A executed only if it has not executed before as well as its
dependencies
= (D), (F), (B), (D), (E), (C), (A) which is identical to (D), (F), (B), (E),
(C), (A) by the virtue that a target is only ever executed once.
* Note: Targets in parentheses only get executed if the have not executed
already; targets listed without parentheses are always forced to execute.
For our builds we need number 5 to work and the proposed depends task would do
just that and hopefully with less confusion since its name implies this sort of
thing. Now my understanding of the call task is that it would do 3, but it
may do 4, not sure as the documentation is a little ambiguous here. So, I
don't think your solution would work unless we had a very simple dependency
tree which we don't.
However, if you like the idea of the proposed depends task I will volunteer to
do all the work that is needed (or that you want me to do). We use NAnt so
much I feel obliged to contribute; we also have a goal to be able to use an
unmodified version. With the latest release we are almost there; changes to
the exec task (see top of thread) and an options attribute for the csc
task are still needed.
James.
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] UPDATE: BUG: Visual-Cpp tasks fail when path for response file contains a space.
Yes, you're absolutely right. The version of NAnt we are using for our builds
is based off the 8.3 release. When I found the error in the Visual-Cpp tasks,
I first checked to see if it was already fixed in the nightly builds, then
patch our version of the source. Once that was fixed, we noticed the same
problem with CSC, and just assumed it was a general problem without checking
the nightly version again.Sorry about that!
BTW, thanks for adding the fix for the Visual-Cpp tasks.
James.
Quoting Gert Driesen [EMAIL PROTECTED]:
James,
I fixed the issues in the Visual Cpp tasks (should be available in the next
nightly build), but I fixed this for the csc compiler before ...
What version of NAnt are you using ?
Gert
- Original Message -
From: James C. Papp [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, November 17, 2003 11:57 PM
Subject: [nant-dev] UPDATE: BUG: Visual-Cpp tasks fail when path for
response file contains a space.
It seems that this a general problem with anything that creates a response
file. I'm seeing the same error the CSC compiler as well.
James.
Quoting James C. Papp [EMAIL PROTECTED]:
BUG: Visual-Cpp tasks fail when path for response file contains a space.
The code currently looks something like this:
...
public override string ProgramArguments {
get {
...
if (Verbose) {
return @ + _responseFileName;
} else {
return /nologo @ + _responseFileName;
}
...
}
}
...
To fix the bug it should be:
...
public override string ProgramArguments {
get {
...
if (Verbose) {
return @\ + _responseFileName + \;
} else {
return /nologo @\ + _responseFileName + \;
}
...
}
}
...
This bug is in ClTask.cs, LibTask.cs, and LinkTask.cs.
For some of you, it may appear that the build works just fine even when
the
temporary response file contains spaces in its path. This can happen if
the
path passed to CL is converted to the old DOS 8.3 short-form, which
removes
any spaces automatically. In fact, this was exactly what was happening
to
me;
I've only notice the problem when I disabled support for 8.3 filename
creation
on my NTFS volume.
I verified that the bug still exists in the latest nightly build; it
would be
great if someone could add these small changes into CVS.
Thanks!
James.
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] UPDATE: BUG: Visual-Cpp tasks fail when path for response file contains a space.
It seems that this a general problem with anything that creates a response
file. I'm seeing the same error the CSC compiler as well.
James.
Quoting James C. Papp [EMAIL PROTECTED]:
BUG: Visual-Cpp tasks fail when path for response file contains a space.
The code currently looks something like this:
...
public override string ProgramArguments {
get {
...
if (Verbose) {
return @ + _responseFileName;
} else {
return /nologo @ + _responseFileName;
}
...
}
}
...
To fix the bug it should be:
...
public override string ProgramArguments {
get {
...
if (Verbose) {
return @\ + _responseFileName + \;
} else {
return /nologo @\ + _responseFileName + \;
}
...
}
}
...
This bug is in ClTask.cs, LibTask.cs, and LinkTask.cs.
For some of you, it may appear that the build works just fine even when the
temporary response file contains spaces in its path. This can happen if the
path passed to CL is converted to the old DOS 8.3 short-form, which removes
any spaces automatically. In fact, this was exactly what was happening to
me;
I've only notice the problem when I disabled support for 8.3 filename
creation
on my NTFS volume.
I verified that the bug still exists in the latest nightly build; it would be
great if someone could add these small changes into CVS.
Thanks!
James.
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Re: RE: RE: [Fwd: Ready to tackle next release] (Patches)
Great! I will need to refresh the source with the latest code under CVS (I'm
currently using code released under v0.83), though I do not think that there
will be many changes. Do you want me to zip up the source files that have
changed and post them to the list, or do you want me to use some tool to
create differences. Does CVS do that? I've used CVS but not extensively, I'm
a Perforce fan.
Also, to clear some confusion:
Matthew, I am referring to Compilerbase.cs as Ian has suggested. I've checked
the latest version under CVS and it has the same problems (actually, it does
not look like the RESX stuff was touched since the v.083 release).
Here's what in CVS now (Compilerbase.cs):
protected virtual string GetFormNamespace(string resxPath) {
string retnamespace = ;
StreamReader sr = null;
// open matching source file if it exists
string sourceFile = resxPath.Replace(resx, Extension);
try {
sr = File.OpenText(sourceFile);
while (sr.Peek() -1) {
string str = sr.ReadLine();
string matchnamespace = @namespace ((\w+.)*);
string matchnamespaceCaps = @Namespace ((\w+.)*);
Regex matchNamespaceRE = new Regex(matchnamespace);
Regex matchNamespaceCapsRE = new Regex(matchnamespaceCaps);
if (matchNamespaceRE.Match(str).Success){
Match namematch = matchNamespaceRE.Match(str);
retnamespace = namematch.Groups[1].Value;
retnamespace = retnamespace.Replace({, );
retnamespace = retnamespace.Trim();
break;
}
else if (matchNamespaceCapsRE.Match(str).Success) {
Match namematch = matchNamespaceCapsRE.Match(str);
retnamespace = namematch.Groups[1].Value;
retnamespace = retnamespace.Trim();
break;
}
}
return retnamespace;
} catch (FileNotFoundException) {
// if no matching file, dump out
return null;
} finally {
if (sr != null) {
sr.Close();
}
}
}
Ellaborting on #2, from this code you can see that regardless of file type the
matchNamespaceCapsRE can still be executed. We were hit by this because at
the top of each of our sorucefiles we have a standard header as well as
documention, and it just so happened to include the word Namespace.
With #3, NAnt does nothing to look for the class name, and just uses the
filename which is not always correct; the path to a RESX file is assocated
with the class name, not the filename.
Matt, you seem to indicate that this type of work is being done somewhere
else. Where is this located, I should take a look at it, to make sure what I
summit is compatible, especially if we want to standardize this stuff in one
place.
Thanks,
James.
Quoting Ian MacLean [EMAIL PROTECTED]:
James,
We'd love to see your patches. The resx issues was a known one - if your
solution is cleaner and more accurate then obviously thats the way to go.
Post patches here and they will be reviewed.
Ian
Quoting Matthew Mastracci
Please let me know if I'm totally out to lunch on this one- I'm guessing
that this resx issue you are describing is a problem with the solution
task.
I haven't really been in the code there lately, but checking in CVS, it
looks as if the resource-compiling functionality is operating correctly
(with the exception of the not-so-smart regex's you mentioned in your
note). I can't see how more than one regex could be run on a single
file. Are you running with an older version, or does CVS exhibit the
problems you are seeing?
Also with regards to The biggest problem is that NAnt assumes the
filename (of the source file) is the name of the class that the RESX
should be associated too- we should (according to the latest code) be
parsing the files to determine the correct namespace/filename of the
final .resource file. Resources should never be named to match their
dependent files. Are you perhaps referring to .resx files that are not
associated with any .cs or .vb files? I could see that there could be a
problem there, but it seems to match VS.NET's behaviour in all of my
tests.
Can you please elaborate on #2 and #3 more? Again, if you're not
talking about what I think you are, let me know, and I apologize in
advance. :)
Thanks,
Matt.
---
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
[nant-dev] RE: RE: [Fwd: Ready to tackle next release]
RE: [Fwd: Ready to tackle next release]
If you are getting ready for a new release, I have a bunch of patches I would
love to see added to NAnt. I would be willing to work with everyone as much
as needed, to see that the changes make it into the release; or some variation
of them - that is, if they are accepted.
Here is a run down of our current changes to NAnt:
I have mentioned this one previously; and it involves adding an options
property to CompilerBase.cs. The original post had no subject and came out
garbled (sorry about that), though I have filed it under RFE [811931] -
Adding an options property to CompilerBase.cs, where you can read about the
change in more detail.
Another change we made was to allow passing of parameters as properties to
other NAnt scripts via the nant task. This works really well and avoids
having to using the inheritall attribute (which can be overkill -
particularly if you have scripts that call themselves externally...). You can
think of this feature as adding support for the -D: options of nant.exe
The syntax looks like this:
nant buildfile=somefile inheritall=false target=sometarget
defines
property name=buildtarget value=${script.build.target} /
property name=copytarget value=${script.copy.target} /
/defines
/nant
The defines are created as properties and accessible only from the invoked
NAnt script as if they were passed with -D:. Their values are evaluated at
the time just before the new script is invoked. Note: You can still use
the inheritall attribute as well, though anything defined will override
anything inherited if there is a name collision. The patch for this change
is straightforward and simple. The only part left to do is handling all the
NAnt location stuff with properties, which I am not too sure about (currently,
I set this to unknown), though I'm sure someone on the list can enlighten me.
Our next change is the most extensive but it fixes a long out-standing issue
with NAnt. Basically, we did a rewrite on how NAnt handles RESX files.
Currently NAnt has the following problems:
1.) The regular expressions for determining the namespace are poor and
are easily confused by comments (that have the word namespace in them, for
example // is located in the foo namespace).
2.) The regular expressions used by different languages are executed on
all the source files. For example, when compiling a *.cs file the regular
expressions for capitalized namespace lookup (I guess for VB) is executed even
when it should not; this is bad, as it picks up false positives and increase
the chance of error.
3.) The biggest problem is that NAnt assumes the filename (of the source
file) is the name of the class that the RESX should be associated too. This
issue killed our use of NAnt (until we fixed it), as our filenames do not
match the Form class within them; Visual Studio does not have a problem with
this.
Our patch fixes all these issues. For number 3, we actually added additional
regular expression that extract the correct class name from the source instead
of assuming it is the same as the file. This works extremely well, mainly
because Visual Studio forces the Form/Control classes to always be the first
class in the file (now you know why they do this, it seems that VS needs to do
all this work as well...).
The way we implemented it was by making a class like this:
protected struct ResourceLinkage {
private string _namespaceName;
private string _className;
public ResourceLinkage(string namespaceName, string className) {
_namespaceName = namespaceName.Trim();
_className = className.Trim();
}
public override string ToString() {
return ...; // Outputs path to resources
}
public string NamespaceName {
get { return _namespaceName; }
set { _namespaceName = value; }
}
public string ClassName {
get { return _className; }
set { _className = value; }
}
}
...to store and keep track of this information. Then we changed the function
that normally returns just a string, to this:
protected virtual ResourceLinkage GetFormResourceLinkage(string resxPath) {}
The regular expressions we use are:
Regex matchNamespaceRE = new Regex(@^\s*namespace ((\w+.)*));
Regex matchNamespaceCapsRE = new Regex(@^\s*Namespace ((\w+.)*));
Regex matchClassNameRE = new Regex(@^([\s\w]*\s)?class\s+(?class\w+));
Anyway, that is the basic gist of it.
There are some issues yet to be resolved. For one, I know nothing about VB
(okay, I know some, but very little), and have not written the Regex patterns
for it. I am also not sure that thee new class-name Regex use successfully
for *.cs files will work for J#.
The Regex patterns can be improved further (though these are problems with the
current version of NAnt as well).
/*
namespace test
class something here
*/
namespace foo {
namespace bar {
class foo : Form { }
}
}
The above examples can still
[nant-dev] options for CompilerBase.cs
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;
/// summaryOptional 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]
---
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
[nant-dev] (no subject)
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 lets 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;
/// summaryOptional 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
