> From: Greg Stein [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 07, 2000 2:01 AM > > > I'm actually contemplating building both the .lib and .dll as two full > > compiles. > > The benefit, when called for, is that users of the .lib won't have dangling > > exported symbols. I refused so far because we have two file lists to > > maintain. > > I'm thinking about a system to auto-generate the entire .dsp as appropriate, > > meaning we don't lug around extra cruft. > > > > If we build the .lib and .dll forms as seperate, full compiles, then this > > issue > > of the nothing file goes away. > > Why are we using two different .dsp files for this? You should be able to > set up the four types of compiles within the single .dsp:
Because the only way the MSVC 5.0 .dsp files may depend on one another are on the same "- Win32 Debug" tag ... only when you get into 6.0 can the dsp of "prog - Win32 Debug" model depend on the "lib - Win32 Debug DLL" dsp. We had the system set up this way a while back, and already nuked it - wouldn't work. > The files are compiled different for release vs debug; are they also > *compiled* differently for DLL vs LIB? Yes ... the .dll forms have more indirections, which point at single instance of fixups rather than the exec process spinning pointers throughout or adding in-module stubs for indirectition. Given all the options, static code linked statically is the fastest, followed by srcs compiled for .dll linkage, and the slowest is static code linked into .dlls (more thunking at run time, plus more symbol refs to fixup at load time.)
