apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: src/ directory (was: Re: apr-util comments)x
Date Thu, 07 Dec 2000 13:26:05 GMT
> From: Greg Stein [mailto:gstein@lyra.org]
> 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.)


Mime
View raw message