From: Bennett, Patrick (Patrick.Bennett_at_[hidden])
Date: 2005-05-26 13:08:35
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> On Behalf Of Victor A. Wagner Jr.
> Sent: Wednesday, May 25, 2005 10:34 PM
> To: boost_at_[hidden]
> Subject: RE: [boost] Customer Friendlier Boost Installation
> At 14:30 2005-05-25, Bennett, Patrick wrote:
> >[Bennett, Patrick] Personally, I think the pragma 'link' options are
> >absolute disaster for large projects.
> apparently you've worked with different folks than I. Likely,
> kinds of "large projects", too.
[Bennett, Patrick] Well, a single full build is over 55 GB. To me at
least, that's large. :)
> >It's far, far too easy to end up with lots of libraries getting
> >in with users having no idea how or why they're being linked against.
> >Since many developers tend to be rather over-eager in #including
> >(bah, just include it all!)
> sounds like "many developers" need to be re-edcuated. or, perhaps,
> need better code walkthroughs.
[Bennett, Patrick] Both. :) That doesn't change the fact that having
object files which contain special decorations (inserted by a
vendor-specific #pragma operation) which cause unspecified libraries to
'automatically' get linked in is a 'bad thing.'
For one, there's no official way to dump a list of these explicit link
references for any given object file or lib/dll.
The only way to (partially) know what might get linked in ahead of time
is to go through a dedicated preprocessor step to verify what's being
linked. Of course, this just handles the case where the public
(interface) headers of all libraries referenced contain pragma/lib
entries. It doesn't account for the libraries which defined pragma/lib
entries for other libraries within their implementation headers [so the
pragma node is only in the linkable file for that static lib or dll's
import lib]. Thus, there's no way to 'know' up-front, and in an
easy/fast manner, what libraries will actually be linked in when
building a dll or exe in the presence of these lib pragma's. They're
bad, bad, bad.
Vendors like Microsoft are certainly welcome to support them, but adding
something like this to the 'standard' would be unacceptable (to me at
least ;>). If tool authors want to provide support for Microsoft's
extension, that's fine too - it should just always be optional.
When it comes to compiling and linking, I don't want the compiler or
linker including anything more than I explicitly told it to include.
If you disagree, well, hey, I guess we'll just have to agree to
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk