I totally agree. Less code duplication the better. Dmitry has used this
approach in the work he has done for VisualC++ projects ie it defers to
the Cl, Midl, rc and link tasks where necessary.
Ian
Erv Walter wrote:
In my opinion, it would be a "good thing" if at some point the
<solution> task did very little work itself. Instead it should
dynamically determine which of the existing tasks should be called and
then call them (instead of calling csc.exe directly, for example). This
would allow the solution task to leverage all of the nice features of
the existing tasks including handling multiple frameworks, etc.
-----Original Message-----
From: Matthew Mastracci [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 04, 2003 12:22 AM
To: Ian MacLean
Cc: James C. Papp; [EMAIL PROTECTED]
Subject: Re: [nant-dev] RE: RE: [Fwd: Ready to tackle next release]
Oh - I hadn't realized that the CompilerBase was doing the same sort of
hackery. In that case, I guess we should probably be sharing the
delicate code between the two places. It might be better to move all of
the code into the CompilerBase class and use it from there in the
Solution task.
Thanks for the clarification,
Matt.
Ian MacLean wrote:
Matthew Mastracci wrote:
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 think he's talking about Compilerbase.cs. The regular compiler tasks
do the same thing as solution task wrt determining correct namespace
prefix. Its the same problem just in a different place.
Ian
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.
On Fri, 2003-10-03 at 21:21, Ian MacLean wrote:
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
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.
It would be great to see NUnit 2.1 plugged in. I'd also like to
see 1.1 as the default. Ian - do you think it would be possible to
get the ReplaceTask into the core if I can make it more robust?
----------------------------------------
- Mitch Denny
- [EMAIL PROTECTED]
- http://www.monash.net
- +61 (414) 610141
-
-----Original Message-----
From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Friday, October 03,
2003 2:31 PM
To: [EMAIL PROTECTED]
Subject: [nant-dev] [Fwd: Ready to tackle next release]
-------------------------------------------------------
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
-------------------------------------------------------
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
-------------------------------------------------------
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
-------------------------------------------------------
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
-------------------------------------------------------
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
