John Maddock wrote:
David Abrahams wrote:
As a Boost user, my point of view that if the docs says I can use plain "msvc" and use autolink, Where does it say that? If that's the case, that's doc bug. In /more/getting_started/windows.html in the Boost 1.34.0 beta package. Specifically look at section 5.2.4 and section 6. Well, if it's not a Boost.Build / BoostAutolink bug, it's certainly surprising. In one context, boost code automatically detects the msvc version and forces a request to a library whose name contains that version number, and in another context, boost code generates a complicated library name, ignoring the version number, that can **never** be linked to by any Boost code unless autolinking is disabled. This should **just work**, and it's possible (probably easy) to implement. Sorry, I just can't accept that it's the fault of the documentation.
I don't think there's anything that autolinking can do to fix this: it requires that libraries are named consistently, and there's no way around that.
So we either need to update the docs, or preferably fix Boost.Build to detect the MSVC version. As Dave says it does this in other contexts already, so it should be possible.
Given the hint that the version number in the tool specification was important I managed to get the right build output names using --tools=msvc-7.1 (took me a couple of tries to work out the right tool name to use). Personally I think a documentation change (clarification?) is enough if it's the only thing holding up the release. It would be perfect if it could do this without the tool specification *and* it could hide warnings that clearly aren't of concern to the libs involved (C4511 no copy constructor can be made - seems to be one). If it is only a matter of getting different output libraries then I can't see that it really helps that much from a presentation point of view. The same benefit can be had from just telling people which --tools command to use and the default I guess works without auto-linking. K