Re: [jamboost] Library file names

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2003-11-28 03:49:08

At Thursday 2003-11-27 23:47, you wrote:
>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.

I'm a boost user, and I've rarely had to change mine...then again, I 
haven't used any of the things that generated libraries until date_time 
and filesystem came along.

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

ALL Of the above are handle by the includes ... the user NEVER sees the 
name of the file.....EVER and you don't have to change the project, just 
rebuild with the new includes (of course, since they didn't have to wait 5 
years for the committee to figure out there's a gaping hole in the spec, 
they implemented #pragma comment(lib, "libraryname") ) which gets around 
the USER having to see all the ugliness underneath. Further notice, they 
didn't have to change anything... install, build, done.

>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 you concentrate on the dynamic linking (i.e. I don't see any 
static linked libraries mentioned). So why don't we just take it as given, 
that I'm more concerned with static linking than dynamic.

BTW, I'm sorry that the unix guys haven't figured out crap that we had 
figured out back in 1985 (go look at how Amiga handled libraries if you 
want to see how sensible solutions work)

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

the file NAMES themselves aren't changed (the path has) it's a HUGE 
difference if you're using Visual Studio.. one simple change in the 
directories to search and ALL projects use the new includes. If we canNOT 
do the same for boost libraries, you doom it them oblivion on windows. I'm 
sure as hell not going to go change many projects "additional dependencies" 
simply because boostoids have released a new 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".

ask me if I care... the POINT was to get the version and platform OUT Of 
the base filename

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

Do you not get it? Linkers don't put things that aren't used into the 
programs they link.
If you're talking about "sharable" libraries yeah, keep 'em separate.
BTW, some small studies we've done at my clients' indicate that generally 
.dll doesn't help the situation at all, they're already bloated with many 
things they're not using, and they get "shared" only rarely. Static 
linking works better for what they to.

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

To clarify, we were a computer manufacturer creating assemblers and 
compilers for our "end users" to use to create THEIR products.
I cannot see the boost community writing something that installs boost for 
me AND fixes all the .vcproj files.
or is there one planned?

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

How nice. Is my "stern talking to" getting through?

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

guess what folks..... MOST programs are written for systems that are NOT 
Linux, Unix, BSD. HELLO!!!!! most computers are WINDOWS!!!!!

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

That's exactly what I'm asking for. I'm just trying to minimize the havoc 
you're going to create with what you have now. I'm happy that you guys 
have some "cute linuxy thing" that will work. But it doesn't help me one 
damned bit. All of my clients use Windows.....ALL of them. I've gotten 
most of them to upgrade to .net2003, and we've been reasonably happy with 
what boost was doing up until now. All of a sudden _I_ have problems at my 
current client's with the new release (things don't build), and I can only 
see it getting worse if we continue in this folly (and it IS folly).

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

I said a .lib NOT a .dll, NOT a .so I trust we all understand the 
difference between static and dynamic linking
if I'd meant dynamic, I would have said .lib AND .dll.

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

if there are some which ARE available as dynamic link and NOT static link, 
then that's another thing that needs fixing.

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

I'm serious folks, I showed a copy of Rene's previous response to a one of 
the ops on the undernet #C++ channel and he said "They expect me go update 
all my projects every time they release boost? They have to be f**king 
kidding."

>--
>-- Grafik - Don't Assume Anything
>-- Redshift Software, Inc. - http://redshift-software.com
>-- rrivera_at_[hidden] - grafik_at_[hidden] - 102708583_at_icq

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