The main point of the local/network lib paths is to
use the lib path as a search path. That is, it
searches the paths in order, using the .lib file from
the first lib path that it finds it in. Makes it
easier to do local development - you can muck with a
local copy of a .lib file without changing
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:
where ${netlib} and ${locallib} would be properties pointing to your network and local
library directories,
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 a
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:
Or something like that. The idea is that anything you specify i
> -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 hav
> 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
> From: Kevin Dente [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 13, 2002 8:08 PM
> To: Nant developer's list
> Subject: Re: Re: [nant-dev] FileSets and multiple directories
>
>
> I don't quite follow you. Whether or not it's a
> Microsoft library or
I don't quite follow you. Whether or not it's a
Microsoft library or one of my own, I still need to
detect whether the library has changed and therefore a
rebuild is required. For either case I need to search
a "library path".
--- Tomas Restrepo <[EMAIL PROTECTED]> wrote:
>
> Kevin,
>
> > The
> -Original Message-
> From: Tomas Restrepo [mailto:[EMAIL PROTECTED]]
>
> Well, the easy way out would be to distinguish between those
> libs that usually don't change (such as those provided by MS
> in VS or PSDK), and those you create in your projects which
> might change often. So
Kevin,
> The problem is not the linker command line - that
> already works. The problem is using Nant to check
> dependencies, so that the task knows if a rebuild (or
> re-link) is necessary.
Well, the easy way out would be to distinguish between those libs that usually don't
change (such as
The problem is not the linker command line - that
already works. The problem is using Nant to check
dependencies, so that the task knows if a rebuild (or
re-link) is necessary.
--- Tomas Restrepo <[EMAIL PROTECTED]> wrote:
> Hi Kevin,
>
> > Has anybody else had a requirement like this? Is
> the
Hi Kevin,
> Has anybody else had a requirement like this? Is there
> some other way to accomplish my goal? Can the fileset
> be extended to support this?
I think FileSets would be the wrong structure to use for this. What I'd like to have
for something like this is an implementation of Ant's Fi
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
13 matches
Mail list logo
