Boost logo

Boost-Build :

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2003-11-27 13:08:42

At Wednesday 2003-11-26 06:20, you wrote:
>Victor A. Wagner, Jr. wrote:
[deleted to conserve bandwidth]
>There have been various list messages about this once upon a time... See the
>"Getting Started" documented in CVS:
>It's not linked in yet, as I'm still working on it, should be done by the
> > ----------except---------
> > is it the intent to keep these names, particularly the "-1_31" part?
> > It is easy to see why library developers might appreciate this, since they
> > could easily tell different versions apart, and even keep them in the same
> > directory.
> > For users, it's a different story entirely. modifying make files (jam
> > files?) or worse, msvc .vcproj files each time a new boost comes out will
> > be a real PITA.
>It's a needed PITA. Boost versions are likely never going to be binary
>compatible enough to make having unversioned names be a reality. Just like
>users will likely have to change there code to deal with changes from version
>to version, changing makefiles is an equivalent conscious decision.

the problem is (as I see it, and it's a VERY SERIOUS problem) that the user
does NOT have to change his code to deal with changes from version to
version. Nobody who releases a library requires all users to change all
projects which use the library.

I notice that the include files are NOT marked in such fashion, and I
believe we can follow the same sort of logic with the library names. We
have boost\include\version\<alltheheaderfiles>
why not boost\lib\version\platform\<allthelibraryfiles>

Tho I think that in the hierarchy that version should come before include
or lib.

> > Also, has been coalescing the libraries such that users might be able
> to do
> > the equivalent of -l boostmt ??
>Now that would be a PITA for Boost library developers.

Without trying to sound TOO pedantic, "better a PITA for you than a PITA
for me"
Seriously though, when I was writing libraries, one of our guidelines was
to minimize the impact on the end user. _Requiring_ a change for all of
our customers simply because _we'd_ decided it was time to update (maybe
stuff they weren't even using) would have gotten one a "very stern talking
to". Actually, it never would have passed the release review process.
Before you suggest that all boost users just need to keep ALL versions of
the library for backwards compatibility is also folly.

I admit (readily, IMO the C++ Committee has let us down severely here) that
the C++ standard doesn't require any behavior on the part of a conforming
compiler to have a method (would be really nice if it was the same method)
for the source code communicating with the linker the need for a library
(kinda like MS's #pragma comment(lib, "libraryfilename") ). No, I'm not
suggesting everyone adopt MS's solution, but SOME solution!

We should strive to get using different parts of the boost libraries no
more difficult than putting the relevant #include "boost/blahblah"
and using statements/directives into the user's source.
as an interim method (until the Committe gets off its duff) creating a
single boost-mt-gd.lib would be a stopgap. That it is difficult should not
deter us.
To be overly melodramatic, I'll borrow a phrase from John F. Kennedy when
challenging us to put a man on the moon.
"We choose to do these things not because they are easy, but because they
are hard."

Victor A. Wagner Jr.
The five most dangerous words in the English language:
"There oughta be a law"


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at