Here is a fix for the problem area. My assumption was this code was trying
to determine the nant.exe file that was running, what folder it was in, and
what the verison number was. I changed the code to use reflection and now
I can't reproduce my problem. This code goes in the project.cs
I found something interesting today.
I'm using a master build file that calls tasks in other build files using
the nant task. In my master build file I have a nant.onsuccess and
nant.onfailure property set to execute after the main build file has either
succeeded or failed. When I call the
Yep, this was something I was thinking about when the inheritance
discussion went on. I was going to clean things up afterwards and test
these cases (which reminds me, we still need unit tests for this).
We really need to separate the project/system props from the user props
so that certain
We really need to separate the project/system props from the
user props
so that certain properties don't get inherited. Or at least
have a block
list that doesn't get inherited.
smells like a good place to use Attributes if you ask me.
__
Andy Smith
Chief Code Monkey
-Original
I'm trying to make some changes to the link task (C++
linker), and am struggling with something. What I'm
trying to do is specify a fileset of library files
that should be linked into the EXE, and be able to
search a set of directories to find the library files.
This is of course a fairly typical
Hi Scott,
We really need to separate the project/system props from the user props
so that certain properties don't get inherited. Or at least have a block
list that doesn't get inherited.
Agreed. I once thought of a way to do so, but can't remember it now :(
Another way to do this is to
I think the point is that the Microsoft libraries change so rarely that
it's not worth finding them, if that's all that you have on the library
search path. Just ignore them and only use your own libraries when
doing the dependency analysis.
Eric.
-Original Message-
From: Kevin Dente
I've ever specified anything other than a
system-like library using a
lib search path. For all of my user sorts of
libraries, I always
specify the complete path name.
That's definitely not the case at my company. We have
dozens of old-style DLLs with import libraries, and we
use a
-Original Message-
From: Kevin Dente [mailto:[EMAIL PROTECTED]]
That's definitely not the case at my company. We have
dozens of old-style DLLs with import libraries, and we
use a library search path for those as well as system libraries.
Then in the proposed scheme you'd have to
Hi Eric,
That's not too bad, I sort of like it. The only drawback is that the
dependency libraries are specified twice, of course.
Not necessarily. What I was thinking about was sort of like this:
link
searchpath=c:\mssdk\lib;c:\
linkto=user32.lib; kernel32.lib;...
Oh, I see what you're saying. I guess that would work
as long as we only have one lib directory for our lib
files. Hmm, I'll think about that. In the past we've
used the notion of local and network lib paths, to
make local development easier, which we'd have to give
up.
I think I can also code
Kevin,
Oh, I see what you're saying. I guess that would work
as long as we only have one lib directory for our lib
files.
Ahh, why? You could just as well use:
dependencies
includes name=${netlib}/mylib1.lib/
includes name=${netlib}/mylib2.lib/
includes
12 matches
Mail list logo
