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 @" + _resp
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.
>
es 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]>
&g
The change to the "call" task makes upgrading our build scripts to the newest
version of NAnt extremely difficult. We used the "call" task as a way to
handle dynamic dependences, which cannot be accomplished with the "depends"
attribute on targets.
If I submit a new task called "depends" that wor
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:
Let's say that task "A" is triggered (via a "call" task, or something equivalent
like
Though..., I'm not sure how a forcedepends flag would help, since isn't that
what call does now? So..., I guess the forcedepends flag would be set to true
by default, and if set to false, it will only execute dependent tasks if they
have not already been executed. But this would not affect the t
> Now, the example of is a little
> ambiguous. Do you mean, don't force "foo" (meaning only execute if it hasn't
> yet), or don't force all the dependencies, or both? Would your on=""/> not force any executions?
To answer your question above, it would be both; that is, not to force the call
*and
DependsTask Patch
Here is an implementation of the task. It allows the use of dynamic
dependencies which was possible with earlier versions of NAnt through the
task, but with current changes is now longer allowed (deprecation of
the force attribute).
It is particularly useful for handling depe
Here is a patch that adds two badly needed features (well..., at least for me
:-)) to the 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
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=31650&atid=402870
James.
"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-expa
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 t
Ian, here is a new version that adds attribute "outputpropertymode". It can be
set to standard, error, or all. The default is all. I've also corrected a small
bug where I was not adding a linefeed to the output.
James.
Quoting Ian MacLean <[EMAIL PROTECTED]>:
> James,
> This looks good. However
; 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"
cantly (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://thinkg
tions” 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
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,
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
Sorry this took so long for me to post, but I wanted to use the latest version
of NAnt source available to me (I pulled it down from the nightly builds).
The version of NAnt we currently use was too outdated and modified, to extract
the changes; it was easier to rewrite the patch from scratch.
19 matches
Mail list logo
