Re: [jamboost] Library file names

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

>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. - http://redshift-software.com
-- rrivera_at_[hidden] - grafik_at_[hidden] - 102708583_at_icq