As my previous e-mail bounced because it was too big (41 KB 40KB limit!)
I'm resending this to the list without the patch.
Again, I encourage everyone to download and try test2 and share your
opinion.
Jarek
- Original Message -
From: Jaroslaw Kowalski [EMAIL PROTECTED]
To: [EMAIL
Where did you find that bit of info ?
Ian
Gert Driesen wrote:
- Original Message -
From: Gert Driesen [EMAIL PROTECTED]
To: Ian MacLean [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Monday, December 08, 2003 7:46 AM
Subject: Re: [nant-dev] Ant's team reaction to msbuild
FYI : the Mono
On Mon, 08 Dec 2003, Ian MacLean [EMAIL PROTECTED] wrote:
thanks Stefan - I didn't realize you had a blog. :)
I'm trying to not push it too hard 8-)
Stefan
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net
http://www.go-mono.com/mono-todo.htm
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, December 08, 2003 8:19 AM
Subject: Re: [nant-dev] Ant's team reaction to msbuild
Where did you find that bit of info ?
Could you just commit to the branch ? I'd like to merge these changes
with my custom function loading code.
Ian
As my previous e-mail bounced because it was too big (41 KB 40KB limit!)
I'm resending this to the list without the patch.
Again, I encourage everyone to download and try test2 and
OK. Committed.
Jarek
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, December 08, 2003 9:23 AM
Subject: Re: [nant-dev] Fw: Expression evaluator changes
Could you just commit to the branch ? I'd like
Awesome, thanks !
Ian
Jaroslaw Kowalski wrote:
OK. Committed.
Jarek
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, December 08, 2003 9:23 AM
Subject: Re: [nant-dev] Fw: Expression evaluator changes
Hi.
Downloaded the nightly build 20031206 and tried to
compile it using NAnt from within a VS .NET prompt.
The results:
[nant] C:\Csharp\nant-20031206\tests\NAnt.Core\NAnt.Core.build build
Buildfile:
file:///C:/Csharp/nant-20031206/tests/NAnt.Core/NAnt.Core
.build
Hi Ian,
What does your custom function loading code do?
I presume that you want to load functions from external dlls and make them
available to EE.
This brings me an idea: as the number of functions EE supports will grow,
we're going to need a concept similar to namespaces and impose some
Now for the larger question, Does everyone want expression support in
NAnt?
I definitely want it! I need it really badly. Currently I'm unable to check
some things correctly without expressions (without script or external
utility). Expression will be very easy in mine case.
It is:
foreach
After the change to
the explicit call behavior, now ensuring all dependencies get called,
there has also been a change to the behavior of depends=
arguments:
These depends
targets now always get called also, even if already
executed.
For
example:
target
name="debug"
Jarek,
What does your custom function loading code do?
I presume that you want to load functions from external dlls and make them
available to EE.
thats correct. It scans assemblies looking for classes marked with a
special attribute - then loads MethodInfo objects from those classes
into a
Hi,
what I think about dash problem:
- in writing xml element names (Nant tasks) is common to use dashes
- we should not disallow this (i'd like to see numeric properties disallowed
though)
I see 2 possible way how to enable use of properties (and even functions)
with dash in name:
A/ allow it
user to specify it. I'm allowing functions to be imported from the same
assemblies that are currently scanned for tasks ie those in the nant bin
dir. Then any extra libs can be added using somthing like the
loadfunctions task you describe below. Maybe loadfunctions could
override namespace
Do you think the functions need to be defined as static ? I was thinking
of making them public instance and passing a Project instance to the
containing objects constructor so that functions can have access to
various information inside the project - the same as tasks can now. It
might be
In that case I should check when I'm scanning for methods that they are
all lowercase - or we can just map a lowercase name to the correct
methodinfo object. So even if you define the method in code as
void SomeFunc()
it will be mapped to the nant custom function somefunc() and attempting
That works. I'd rather specifiy the namespace at the class level though.
Ian
In that case I should check when I'm scanning for methods that they are
all lowercase - or we can just map a lowercase name to the correct
methodinfo object. So even if you define the method in code as
void SomeFunc()
At some point I'd like to use the multiple .resx input of resgen.exe -
it would be nice to swallow output if no errors occur and just output:
[resgen] Transformed 5 .resx files
The solution builds would be a lot easier to read. Perhaps I can
compress all of the reference copy
Hi,
what I think about dash problem:
- in writing xml element names (Nant tasks) is common to use dashes
Agreed.
I see 2 possible way how to enable use of properties (and even
functions)
with dash in name:
A/ allow it on lexical level:
So: if test=${some-long-property -
the problem is with resources, sorry!
Another problem with resources, I've discovered that since it creates a copy
of the ressources files with the full name that the resources will have,
which make my build fail due to the fact that the resulting full path to the
file is too long.
Hi Martin,
I reconsidered your arguments for lexical separation, and I tend to think
that this might be a way to go during the transition period.
A/ allow it on lexical level:
So: if test=${some-long-property - long-function(1)=42}/ it means
prop - func(1)=42
but if
I have committed the changes to fix this behavior.
I will be committing tests later to confirm my expectations, and so this
behavior doesn't change without notice again.
In short, things should work like
this:
--Targetsspecified on the command line, or
via the nant task, should execute
I have found a bug in the solution build task when the project default root
namespace is an empty string. The embeded resource namespace starts with a
'.' when it shouldn't. For examlple, I have a vb class that has a namespace
of Test.Project and the project does not have a Root Namespace
Thanks Nick,
I tracked down the cause of this from an earlier bug report an am
working on fix. Thanks for the detailed report.
Ian
N. V. wrote:
the problem is with resources, sorry!
Another problem with resources, I've discovered that since it creates
a copy of the ressources files with the
Lets hold up till I get the custom function loading stuff committed.
Should be later today or tomorrow.
Ian
What do you think?
Can we merge EE-patches with main branch as soon as we have this semantics
implemented?
Jarek
---
This SF.net
Hi Paul
Which version of nant are you using ? A recent change in the solution
task should fix that issue. Either the latest nightly or 0.84 beta 1
will have the fix.
beta 1 has a known issue where it fails to build its test library with
the following error :
build:
[csc]
I really need it too. +1
- Mitch Denny
- [EMAIL PROTECTED]
- http://www.monash.net
- +61 (414) 610141
-
-Original Message-
From: Martin Aliger [mailto:[EMAIL PROTECTED]
Sent: Monday, 8 December 2003 11:17 PM
To: Scott Hernandez; [EMAIL
27 matches
Mail list logo
