> 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 library search path for those as well as system libraries. --- "Smith, Eric V." <[EMAIL PROTECTED]> wrote: > > -----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 you could have, perhaps, a > > "dependencies" fileset, besides the usual list of > libraries > > to link to. (Of course, you'd add the libs in > "dependencies" > > to the linker command line so that they are linked > in, too). > > This would be similar to how VS does it, I > think... > > That's not too bad, I sort of like it. The only > drawback is that the > dependency libraries are specified twice, of course. > > I find that this wouldn't be a practical problem > because I don't think > 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. For this you could > do: > > <lib-search-path> > <includes name="/some/system/like/path"/> > </lib-search-path> > <dependent-libraries> > <includes name="/path/to/my/library.lib"/> > </dependent-libraries> > <non-dependent-libraries> > <includes asis="true" name="runtime.lib"/> > </non-dependent-libraries> > > Where runtime.lib is some library that isn't likely > to change and I > don't need my build to be dependent on it. > > For the purposes of building the link.exe command > line these 2 sets of > .lib files are treated the same. For the purposes > of calculating > NeedsCompiling dependencies, it would just use the > <dependent-libraries> > group. It would be an error to have a > <dependent-libraries> file that > you couldn't find via it's relative or absolute > path. The link task > would not look at <lib-search-path>'s to find those > files for purposes > of NeedsCompiling. > > The element names here are hideous, you'll probably > want to pick better > names. > > If you really wanted to have libraries (such as > runtime.lib in this > example) treated as dependencies, you'd probably > need a separate > <dependencies> (as suggested by Tomas) that just > specifies files used as > dependents and are not used in generating the > command line. As I said, > in practice I'd never need the <dependencies>, which > is a bonus. > > > > Looking back on this, it looks sort of complex, but > I can't think of a > simpler way to achieve what we need. > > Eric. > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application > Developer's Conference > August 25-28 in Las Vegas - > http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Nant-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/nant-developers __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
