-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Victor A. Wagner Jr. Sent: Wednesday, May 25, 2005 10:34 PM To: boost@lists.boost.org Subject: RE: [boost] Customer Friendlier Boost Installation

At 14:30 2005-05-25, Bennett, Patrick wrote:

...

[delete] [Bennett, Patrick] Personally, I think the pragma 'link' options are an absolute disaster for large projects.

apparently you've worked with different folks than I. Likely, different kinds of "large projects", too.

...

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

[Bennett, Patrick] Well, a single full build is over 55 GB. To me at least, that's large. :) linked headers

...

(bah, just include it all!)

sounds like "many developers" need to be re-edcuated. or, perhaps, you 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 disagree. Cheers... Patrick Bennett