With respect to http://www.boost-consulting.com/boost/more/separate_compilation.html, I note that: * It needs to be updated for BBv2 * It has a rationale section called "Why static linking by default?" but that's the first mention of static linking in the document. Is there a section missing? Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Also, I know we've been over this before, but is there a good reason we can't use more descriptive names than BOOST_XXX_NO_LIB ? It seems to me that BOOST_XXX_NO_AUTO_LINK would be more suitable. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
I now see from reading between the lines that if we follow the prescription in this file, auto-linking will be disabled unless BOOST_MYLIB_DYN_LINK is #defined. However, it doesn't say whether BOOST_MYLIB_DYN_LINK should be #defined by default. I think this should be clarified. More to the point, I question our choice of *not* auto-linking by default. The latest "Getting Started" guide describes how selecting the right library to link with can be problematic, and how auto-linking relieves most of that burden. It seems misguided to ask newbie users to add BOOST_ALL_DYN_LINK (or something) to the command-line when they want the convenience of auto-linking just so that people writing real applications will get their usual preference for static or dynamic linking without adding -D to the command line. I think the latter group can be assumed to be more sophisticated and better able to handle a tiny bit of complexity in the build configuration. I strongly favor making things as easy as possible for the newbie. Comments? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
From my own observations I think the above conclusion is incorrect. In my own projects I have to manually turn *off* auto-linking, by defining BOOST_ALL_NO_LIB. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
David Abrahams wrote:
Well then, I guess I really don't know how to interpret that web page and will need some help from its author. John?
It's on by default, BOOST_XXX_DYN_LINK forces it to choose to link against a dll rather than a static lib (when such a choice exists). John.
David Abrahams <dave@boost-consulting.com> writes:
Oh, but that brings up another issue. The default of static linking doesn't make sense for Boost.Python: if you link your extension module statically it will be bigger than necessary and you'll give up an important feature of the library, which allows multiple extension modules to interoperate with the same wrapped C++ types. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Absolutely, there is no one policy that fits all. The rationale for the current behaviour was this: originally regex (from which all this stuff originates) used dynamic linking by default when the runtime was dynamic. It's safer that way should you be using regex from a dll for example. However, it brought a persistent stream of user complaints: mainly about deployment, all asking if static linking could be the default. After I changed the complaints stopped, and I've never had one about static linking by default being the wrong choice. There is a (admittedly breif) note at the end of the "Why static linking by default?" section to the effect that this might not be the best policy for everyone. Boost.Python seems to me to be exactly the case where it's not the best policy BTW. John.
"John Maddock" <john@johnmaddock.co.uk> writes:
OK, that speaks volumes, thanks. Still, the document really ought to be more explicit about how static linking is the default rather than making the reader deduce it from the rationale section. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
David Abrahams -
John Maddock -
Rene Rivera