Re: [jamboost] Library file names

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:
>
> http://www.boost-consulting.com/boost/more/getting_started.html
>
>It's not linked in yet, as I'm still working on it, should be done by the 
>weekend.
>
> > ----------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. http://rudbek.com
The five most dangerous words in the English language:
"There oughta be a law"