Boost logo

Boost-Build :

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
> version.

I'm a Boost user and I've _had_ to change my code for _every_ version release
of Boost.

>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 ->
msvcp71.dll ...

GTK; ->; ->

libpng; ->

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?

>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>

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
>>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"

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
> to".

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. -
-- rrivera_at_[hidden] - grafik_at_[hidden] - 102708583_at_icq

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