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
