[nant-dev] [ nant-Bugs-1423931 ] comments description is missing in msdn like help...
Bugs item #1423931, was opened at 2006-02-04 02:15 Message generated for change (Comment added) made by garyfx You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1423931group_id=31650 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: 0.85 Status: Open Resolution: None Priority: 7 Submitted By: Pooja (pooja_sh5) Assigned to: Nobody/Anonymous (nobody) Summary: comments description is missing in msdn like help... Initial Comment: Have downloaded NAnt 0.85 nightly build to support .net framework 2.0 but while creating MSDN like documentation using task ndoc, no comments are present at all under Description column. Whereas comments specified within all the tags(summary, remarks, params etc) are present in the generated xml files. Please suggest. If NDoc version is not the updated one then please fix this issue.. Thanks in advance. -- Comment By: Gary Feldman (garyfx) Date: 2006-05-16 08:53 Message: Logged In: YES user_id=847172 I've lowered the priority of this, on the basis that it only affects one specific task, and the task itself is non-critical. -- Comment By: Pooja (pooja_sh5) Date: 2006-02-08 01:54 Message: Logged In: YES user_id=1443619 In the NAnt.chm file description field is not showing the appropriate info. Am not able to attch the zip file containg code. Hope this info. is sufficient for providing help. In case of further ref. please contact soon. Thanks -- Comment By: Gert Driesen (drieseng) Date: 2006-02-07 06:54 Message: Logged In: YES user_id=707851 Can you send me a repro for this issue ? Thanks ! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1423931group_id=31650 --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-1474159 ] Call Target and cascade=false prevents target re-execution
Bugs item #1474159, was opened at 2006-04-21 07:50
Message generated for change (Settings changed) made by garyfx
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=402868aid=1474159group_id=31650
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tasks
Group: 0.85
Status: Open
Resolution: Postponed
Priority: 7
Submitted By: [EMAIL PROTECTED] (mike_at_rubicon)
Assigned to: Gert Driesen (drieseng)
Summary: Call Target and cascade=false prevents target re-execution
Initial Comment:
When I set the cascade flag to flase on the call task,
the called target it self is not re-executed.
project default=build
target name=init /
target name=compile depends=init /
target name=build
call target=compile cascade=false /
call target=compile cascade=false /
/target
/project
Expected behavior:
build:
init:
compile:
compile:
Actual behavior:
build:
init:
compile:
I'm using the nightly from 2006-03-08
I believe it's a problem in Project.cs
public void Execute(string targetName, bool
forceDependencies)
lines 884 and 885
if (forceDependencies || !currentTarget.Executed) {
currentTarget.Execute();
}
currentTarget will eventually end up being the called
target, and its execution state is checked just like if
its another of the depended targets.
--
Comment By: Gary Feldman (garyfx)
Date: 2006-05-16 08:50
Message:
Logged In: YES
user_id=847172
Sorry for not responding to your clarification earlier, but
yes, I now think you are correct.
The call task has direct and indirect targets. The direct
target is the one named in the target=target-name
attribute. The indirect targets are the dependencies of the
direct target.
The documentation says that the direct target will always be
executed, but the indirect targets will only be executed if
they haven't been executed before OR if cascade is true.
However, the code treats the direct target the same as
indirect targets, so it won't be executed if it has already
executed, unless cascade is true. The example in the
documentation serves as a good reproducer.
I also agree with both the documentation and Mike's
expectation, which is that the direct target should always
be executed, which means I disagree with Gert's initial
comment here.
The fix, unfortunately, is non-trivial. The dependency
logic is in Project.Execute, which is a public method that
shouldn't be changed without ensuring that its clients won't
break. My guess is that's ok, but it means reviewing all
calls on it from both NAnt and NAntContrib code. There are
other approaches, but this would produce the cleanest code.
Since there's a documented workaround, fixing this can be
postponed beyond 0.85.
--
Comment By: [EMAIL PROTECTED] (mike_at_rubicon)
Date: 2006-05-16 02:04
Message:
Logged In: YES
user_id=1505249
Reopened, since documentation and code still contradict each
other, as shown in my last comment.
--
Comment By: [EMAIL PROTECTED] (mike_at_rubicon)
Date: 2006-05-01 14:21
Message:
Logged In: YES
user_id=1505249
--- From the remarks section ---
When the CallTask is used to execute a target, both that
target and all its dependent targets will be re-executed. To
avoid dependent targets from being executed more than once,
two options are available: ... Set the CascadeDependencies
attribute to false.
---
This remark never states that the actual called target will
not be re-executed. Admittedly, it also doesn't say otherwise ;)
More important, the example on compiling a debug and a
release build shows that the called target should be
re-executed:
--- From the example in the xml comment ---
/// project default=build
/// property name=debug value=false /
/// target name=init
/// echo message=initializing /
/// /target
/// target name=compile depends=init
/// echo message=compiling with debug = ${debug} /
/// /target
/// target name=build
/// property name=debug value=false /
/// call target=compile /
/// property name=debug value=true /
/// call target=compile /
/// /target
/// /project
...
/// The CascadeDependenciesparameter of the CallTask
/// defaults to true, causing the init target to be
/// executed for both the debug and release build.
...
/// build:
/// init:
/// [echo] initializing
/// compile:
/// [echo] compiling with debug = false
/// init:
/// [echo] initializing
/// compile:
/// [echo] compiling with debug = true
/// BUILD SUCCEEDED
...
/// If the init should only be executed once, set the
/// CascadeDependencies attribute of the CallTask to false.
...
/// build:
/// init:
/// [echo] initializing
/// compile:
///
[nant-dev] Bug tracking status
There are currently no open P9 bugs. Only two bugs were submitted in the first half of May, nine in all of April. Of the nine in April, two were duplicates, one had already been fixed, one was user error, one has been fixed, two are pending more information. I've marked one of them postponed, because I don't believe it's needed for 0.85. Only one of the two May bugs looks like it needs to be addressed (1481841 exec task's commandline and arg eat = signs https://sourceforge.net/tracker/index.php?func=detailaid=1481841group_id=31650atid=402868 ), but I suspect that arg value... can be made to work. In my opinion, that's enough to close out 0.85 and release it. Granted, I'm exploiting the fact that the default priority is 5, not 9. Nevertheless, 0.85 is still a pre-1.0 version number and there's more noise about getting a new release out than fixing any particular bug. Furthermore, a release is really necessary at this time to maintain credibility against MSbuild. Therefore, I propose that the next full build be declared the 0.85 final release, and that 0.86 be opened. The only exception to this would be any identified showstoppers, where showstopper is defined as: a) it affects most NAnt users; b) there is no workaround; and either c1) it prevents using NAnt for its primary purpose (building .Net projects) or c2) the fix would break many existing build files. I can even be convinced to remove c2, but I doubt that's an issue. Gary --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-1474159 ] Call Target and cascade=false prevents target re-execution
Bugs item #1474159, was opened at 2006-04-21 07:50
Message generated for change (Comment added) made by garyfx
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=402868aid=1474159group_id=31650
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tasks
Group: 0.85
Status: Open
Resolution: Postponed
Priority: 5
Submitted By: [EMAIL PROTECTED] (mike_at_rubicon)
Assigned to: Gert Driesen (drieseng)
Summary: Call Target and cascade=false prevents target re-execution
Initial Comment:
When I set the cascade flag to flase on the call task,
the called target it self is not re-executed.
project default=build
target name=init /
target name=compile depends=init /
target name=build
call target=compile cascade=false /
call target=compile cascade=false /
/target
/project
Expected behavior:
build:
init:
compile:
compile:
Actual behavior:
build:
init:
compile:
I'm using the nightly from 2006-03-08
I believe it's a problem in Project.cs
public void Execute(string targetName, bool
forceDependencies)
lines 884 and 885
if (forceDependencies || !currentTarget.Executed) {
currentTarget.Execute();
}
currentTarget will eventually end up being the called
target, and its execution state is checked just like if
its another of the depended targets.
--
Comment By: Gary Feldman (garyfx)
Date: 2006-05-16 08:50
Message:
Logged In: YES
user_id=847172
Sorry for not responding to your clarification earlier, but
yes, I now think you are correct.
The call task has direct and indirect targets. The direct
target is the one named in the target=target-name
attribute. The indirect targets are the dependencies of the
direct target.
The documentation says that the direct target will always be
executed, but the indirect targets will only be executed if
they haven't been executed before OR if cascade is true.
However, the code treats the direct target the same as
indirect targets, so it won't be executed if it has already
executed, unless cascade is true. The example in the
documentation serves as a good reproducer.
I also agree with both the documentation and Mike's
expectation, which is that the direct target should always
be executed, which means I disagree with Gert's initial
comment here.
The fix, unfortunately, is non-trivial. The dependency
logic is in Project.Execute, which is a public method that
shouldn't be changed without ensuring that its clients won't
break. My guess is that's ok, but it means reviewing all
calls on it from both NAnt and NAntContrib code. There are
other approaches, but this would produce the cleanest code.
Since there's a documented workaround, fixing this can be
postponed beyond 0.85.
--
Comment By: [EMAIL PROTECTED] (mike_at_rubicon)
Date: 2006-05-16 02:04
Message:
Logged In: YES
user_id=1505249
Reopened, since documentation and code still contradict each
other, as shown in my last comment.
--
Comment By: [EMAIL PROTECTED] (mike_at_rubicon)
Date: 2006-05-01 14:21
Message:
Logged In: YES
user_id=1505249
--- From the remarks section ---
When the CallTask is used to execute a target, both that
target and all its dependent targets will be re-executed. To
avoid dependent targets from being executed more than once,
two options are available: ... Set the CascadeDependencies
attribute to false.
---
This remark never states that the actual called target will
not be re-executed. Admittedly, it also doesn't say otherwise ;)
More important, the example on compiling a debug and a
release build shows that the called target should be
re-executed:
--- From the example in the xml comment ---
/// project default=build
/// property name=debug value=false /
/// target name=init
/// echo message=initializing /
/// /target
/// target name=compile depends=init
/// echo message=compiling with debug = ${debug} /
/// /target
/// target name=build
/// property name=debug value=false /
/// call target=compile /
/// property name=debug value=true /
/// call target=compile /
/// /target
/// /project
...
/// The CascadeDependenciesparameter of the CallTask
/// defaults to true, causing the init target to be
/// executed for both the debug and release build.
...
/// build:
/// init:
/// [echo] initializing
/// compile:
/// [echo] compiling with debug = false
/// init:
/// [echo] initializing
/// compile:
/// [echo] compiling with debug = true
/// BUILD SUCCEEDED
...
/// If the init should only be executed once, set the
/// CascadeDependencies attribute of the CallTask to false.
...
/// build:
/// init:
/// [echo] initializing
/// compile:
/// [echo]
RE: [nant-dev] Bug tracking status
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary Feldman Sent: dinsdag 16 mei 2006 17:32 To: nant-developers@lists.sourceforge.net Subject: [nant-dev] Bug tracking status There are currently no open P9 bugs. Only two bugs were submitted in the first half of May, nine in all of April. Of the nine in April, two were duplicates, one had already been fixed, one was user error, one has been fixed, two are pending more information. I've marked one of them postponed, because I don't believe it's needed for 0.85. Only one of the two May bugs looks like it needs to be addressed (1481841 exec task's commandline and arg eat = signs https://sourceforge.net/tracker/index.php?func=detailaid=148 1841group_id=31650atid=402868 ), but I suspect that arg value... can be made to work. Gary, were you able to reproduce this issue ? It's working fine here. I think that the issue described by the submitter is due to the way command line arguments for batch files are processed, and as such this has nothing to do with NAnt itself. In my opinion, that's enough to close out 0.85 and release it. Granted, I'm exploiting the fact that the default priority is 5, not 9. Nevertheless, 0.85 is still a pre-1.0 version number and there's more noise about getting a new release out than fixing any particular bug. Furthermore, a release is really necessary at this time to maintain credibility against MSbuild. Therefore, I propose that the next full build be declared the 0.85 final release, and that 0.86 be opened. The only exception to this would be any identified showstoppers, where showstopper is defined as: a) it affects most NAnt users; b) there is no workaround; and either c1) it prevents using NAnt for its primary purpose (building .Net projects) or c2) the fix would break many existing build files. I can even be convinced to remove c2, but I doubt that's an issue. I'd still prefer to have one more release candidate before we ship a new final release. I hope to have time in the next two weeks, but I realise I've said that before :( We've also lost the instructions for our release procedure when the Wiki was killed (pfff), so it'll take a little longer than usually. Gert --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Bug tracking status
Gert Driesen wrote: Gary, were you able to reproduce this issue ? It's working fine here. I think that the issue described by the submitter is due to the way command line arguments for batch files are processed, and as such this has nothing to do with NAnt itself. I didn't try, because my intuition agrees with your analysis. I'd still prefer to have one more release candidate before we ship a new final release. OK, but let's pick a time frame for the interval between that and the real release, along with a policy of no checkins (on the trunk) during that period except for showstoppers. Gary --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-1474159 ] Call Target and cascade=false prevents target re-execution
Bugs item #1474159, was opened at 2006-04-21 13:50
Message generated for change (Comment added) made by mike_at_rubicon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=402868aid=1474159group_id=31650
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tasks
Group: 0.85
Status: Open
Resolution: None
Priority: 5
Submitted By: [EMAIL PROTECTED] (mike_at_rubicon)
Assigned to: Gert Driesen (drieseng)
Summary: Call Target and cascade=false prevents target re-execution
Initial Comment:
When I set the cascade flag to flase on the call task,
the called target it self is not re-executed.
project default=build
target name=init /
target name=compile depends=init /
target name=build
call target=compile cascade=false /
call target=compile cascade=false /
/target
/project
Expected behavior:
build:
init:
compile:
compile:
Actual behavior:
build:
init:
compile:
I'm using the nightly from 2006-03-08
I believe it's a problem in Project.cs
public void Execute(string targetName, bool
forceDependencies)
lines 884 and 885
if (forceDependencies || !currentTarget.Executed) {
currentTarget.Execute();
}
currentTarget will eventually end up being the called
target, and its execution state is checked just like if
its another of the depended targets.
--
Comment By: [EMAIL PROTECTED] (mike_at_rubicon)
Date: 2006-05-16 08:04
Message:
Logged In: YES
user_id=1505249
Reopened, since documentation and code still contradict each
other, as shown in my last comment.
--
Comment By: [EMAIL PROTECTED] (mike_at_rubicon)
Date: 2006-05-01 20:21
Message:
Logged In: YES
user_id=1505249
--- From the remarks section ---
When the CallTask is used to execute a target, both that
target and all its dependent targets will be re-executed. To
avoid dependent targets from being executed more than once,
two options are available: ... Set the CascadeDependencies
attribute to false.
---
This remark never states that the actual called target will
not be re-executed. Admittedly, it also doesn't say otherwise ;)
More important, the example on compiling a debug and a
release build shows that the called target should be
re-executed:
--- From the example in the xml comment ---
/// project default=build
/// property name=debug value=false /
/// target name=init
/// echo message=initializing /
/// /target
/// target name=compile depends=init
/// echo message=compiling with debug = ${debug} /
/// /target
/// target name=build
/// property name=debug value=false /
/// call target=compile /
/// property name=debug value=true /
/// call target=compile /
/// /target
/// /project
...
/// The CascadeDependenciesparameter of the CallTask
/// defaults to true, causing the init target to be
/// executed for both the debug and release build.
...
/// build:
/// init:
/// [echo] initializing
/// compile:
/// [echo] compiling with debug = false
/// init:
/// [echo] initializing
/// compile:
/// [echo] compiling with debug = true
/// BUILD SUCCEEDED
...
/// If the init should only be executed once, set the
/// CascadeDependencies attribute of the CallTask to false.
...
/// build:
/// init:
/// [echo] initializing
/// compile:
/// [echo] compiling with debug = false
/// compile:
/// [echo] compiling with debug = true
/// BUILD SUCCEEDED
---
What I interpret into this piece of documentation:
Compile is executed using the CallTask. And with cascade
set to false, the example's output shows that compile
should be re-executed, and only init, on which compile
depends on, would not be re-executed.
But the actual code, and your explaination, indicate that
compile shouldn't be re-executed either.
So the second part of the example and the code contradict
each other and should be brought back into sync.
--
Comment By: Gary Feldman (garyfx)
Date: 2006-05-01 19:48
Message:
Logged In: YES
user_id=847172
The internal documentation in CallTask.cs looks correct to
me, which is not to say it couldn't be made clearer.
Exactly which sentence or sentences are you interpreting as
saying the opposite?
--
Comment By: [EMAIL PROTECTED] (mike_at_rubicon)
Date: 2006-05-01 16:32
Message:
Logged In: YES
user_id=1505249
Thanks for clarifying. May I recommend updating the
call-task's xml-comment, because it explicitly states otherwise.
--
Comment By: Gert Driesen (drieseng)
Date: 2006-05-01 16:16
Message:
Logged In: YES
user_id=707851
This is actually by design. The call task
RE: [nant-dev] Bug tracking status
Great! I think NAnt needs new release badly. The fact, it has no stable release for year or so hurt the project, imho. Next thing we should do is VS2005 projects. I prefer msbuild integration way, but its 0.86 or rather 0.9 matter! btw: it'd be better to release atleast 2 or 4 version a year, even that not so well tested, perhaps. We could always rerelease patched version. Regards, Martin Aliger In my opinion, that's enough to close out 0.85 and release it. Granted, I'm exploiting the fact that the default priority is 5, not 9. Nevertheless, 0.85 is still a pre-1.0 version number and there's more noise about getting a new release out than fixing any particular bug. Furthermore, a release is really necessary at this time to maintain credibility against MSbuild. Therefore, I propose that the next full build be declared the 0.85 final release, and that 0.86 be opened. The only exception to this would be any identified showstoppers, where showstopper is defined as: a) it affects most NAnt users; b) there is no workaround; and either c1) it prevents using NAnt for its primary purpose (building .Net projects) or c2) the fix would break many existing build files. I can even be convinced to remove c2, but I doubt that's an issue. Gary --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-1417152 ] solution task fails to compile Unicoded MFC projects
Bugs item #1417152, was opened at 2006-01-27 19:35 Message generated for change (Comment added) made by icnocop You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1417152group_id=31650 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: 0.85 Status: Open Resolution: None Priority: 5 Submitted By: icnocop (icnocop) Assigned to: Nobody/Anonymous (nobody) Summary: solution task fails to compile Unicoded MFC projects Initial Comment: Hello. I am running NAnt 0.85 (Build 0.85.2173.0; nightly; 12/13/2005) I am experiencing the problem initially reported here: http://www.mail-archive.com/nant- [EMAIL PROTECTED]/msg08202.html START QUOTE To reproduce the error: Create a standard MFC dialog application [C++] From inside Visual Studio I change the 'Character set' property to 'Use Unicode Character Set' (the default value is 'Use Multi-Byte Character Set'). This causes '-D _UNICODE' and '-D UNICODE' to be added to the compiler command line. But it also adds an '/ENTRY:wWinMainCRTStartup' option to the linker command line. When I compile the thing from Visual Studio it produces a working application. Nant, however, seems to neglect the character set property, when it comes to linking. [link] msvcrtd.lib(crtexew.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _WinMainCRTStartup END QUOTE However, the error I am seeing is this: [link] libcmt.lib(wincrt0.obj) : error LNK2019: unresolved exte rnal symbol [EMAIL PROTECTED] referenced in function _WinMainCRTStartup [link] C:\Work\Solution\Project\Release\Test.exe : fatal error LNK1120: 1 unr esolved externals Thank you. -- Comment By: icnocop (icnocop) Date: 2006-05-16 20:00 Message: Logged In: YES user_id=1108985 I've just uploaded a test unicode solution that fails with NAnt 0.85-nightly-2006-04-30. In order to make nant successfully build the solution, you have to manually enter wWinMainCRTStartup in the Entry Point field of the Linker Advanced Project properties window. -- Comment By: Gert Driesen (drieseng) Date: 2006-01-28 00:38 Message: Logged In: YES user_id=707851 Can you attach a small repro for this issue (or send one to me by email) ? Thanks ! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1417152group_id=31650 --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
