From: Rene Rivera (grafik.list_at_[hidden])
Date: 2003-11-28 01:47:37
Victor A. Wagner, Jr. wrote:
> At Wednesday 2003-11-26 06:20, you wrote:
>>Victor A. Wagner, Jr. wrote:
>>>is it the intent to keep these names, particularly the "-1_31" part?
>>>For users... 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
I'm a Boost user and I've _had_ to change my code for _every_ version release
>Nobody who releases a library requires all users to change all
> projects which use the library.
Yes they do; examples:
Microsoft; d3d8.dll -> d3d9.dll, ctl3d32.dll -> ctl3dv2.dll, dx7vb.dll ->
dx8vb.dll, mfc40.dll -> mfc42.dll -> mfc71.dll; msvcp50.dll -> msvcp60.dll ->
GTK; libglib-1.2.so -> libglib-2.0.so; libgtk-1.2.so -> libgtk-2.0.so
libpng; libpng10.so -> libpng12.so
Linux, BSD, and most Unices; lib<name>.so.<major>.<minor>.<patch>
> I notice that the include files are NOT marked in such fashion,
They are installed in <destination>/include/boost-1_31/... How is that NOT
marking them with the version?
> 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>
Because the destination doesn't have to be ".../boost". On non-Windows the
destination defaults to "/usr/local".
>>>Also, has been coalescing the libraries such that users might be able
>>>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"
OK... Myself, as a user, it would be a PITA. I would not like to pay, in load
size, for code I would not use.
> Seriously though, when I was writing libraries, one of our guidelines was
> to minimize the impact on the end user.
An end user is different than a library user. As a product developer I remove
that impact with isolation, a comprehensive installer, or an automated updater.
>_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
As lead developer in many projects, and President of my company I'm the one
who usually does the "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.
1. It's not folly.
2. Users (or the installer/updaters acting for the users) will eventually
remove the old versions when they are no longer needed.
3. It's the de-facto standard in Linux, Unix, BSD, etc.
> 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.
I, and others in Boost, are trying to solve the reality of users asking for a
standardized build/install of the Boost libraries.
> 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 give an idea of the difficulty I suggest you try and create such a
library/dll/so -- and tell us how to do it. But I can just see the pain in
trying to merge DLLs that have different, but named the same, inits. And bear
in mind some libraries are not available as DLLs/SOs, while others are not
available as LIBs.
> 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."
Irrelevant, but cute ;-)
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera_at_[hidden] - grafik_at_[hidden] - 102708583_at_icq
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk