Re: [jamboost] Library file names

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2003-11-28 10:17:13

OK, point by point....
At Friday 2003-11-28 03:20, you wrote:
>Victor A. Wagner, Jr. wrote:
>
> > >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)
>
>Victor, maybe you can stop expressing your bad attitude towards UNIX?

That you read my comments that way is unfortunate. I'll try to be plainer.

> This is
>not going to help your with convincing anybody in anything. Besides, if you
>have an idea to propose, you could have did it better than sending us to
>1985.

I wasn't sending you anywhere. I was pointing out that a solution to some 
of these problems existed 18 years ago and that it seems to have been 
ignored ever since. It consisted of having the LoadLibrary() function take 
an optional version. The call would fail if a library of the asked for or 
later couldn't be found.

>Finally, you should not feel sorry for unix guys, really. When somebody wants
>to use, say boost regex, on Debian Linux, he just says:
>
> g++ <many-options> -lboost_regex

Neat trick. Have you tried that with the current CVS build and getting 
1.31 files?
All I'm asking that we be able to do the same thing on 
windows...unfortunately when you bury the version in the filename, you 
leave Visual Studio (VS) users with no choice except to change their 
project setups. Due to the way VS works, it's easy to make global changes 
to the path that will be searched for files, but not for 
mangling/decorating the files themselves.

>and uses whatever version is installed on the system. In fact, I think it's
>probably be good if install process created the proper symlinks from
>libboost_regex.so to libbost_regex.$version_number.so. That would at least
>help packaging, and not do any harm.

Again, I wasn't talking about dynamic linking; Different can of worms.
Creating symlinks/hardlinks/whatever would be a solution also...can we get 
it added to the "install"?

> > > > 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.
>
>So, you'd like boost_regex.1.31.0.lib to be boost_regex.lib? Hmm... is it all
>that hard to rename that manually or via script after you download new boost
>release. It's probably possible to make a copy with this name during
>installing, but IMO this is not so complex task as to doom boost into
>oblivion.

reading the command:
bjam -sTOOLS=blahblah install

leaves one with the impression that it has actually installed something 
useful on the system.
What it currently leaves is something that now requires manual intervention 
(perhaps a lot of it).
All I've been doing is suggesting that perhaps something else would be more 
useful.
As for how complex it is to rename/copy all of the files, I don't 
know. Doing it manually certainly is tedious since 36 files are currently 
created.

> > > > 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!!!!!
>
>Again, please stop making statements like this. This is just flame.

No, it's not a flame. It's intended to wake up all the people who think 
that *nix is the end all of computing. A solution for *nix solve YOUR 
problem, it doesn't do anything for mine.

> > >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.
>
>Maybe, you can tell us how to create static library, then? Do you know of any
>standard tool which takes several static libraries and create one merged one?
>Or do you volunteer to write such a tool?

I don't know of such a tool. Apparently there's one that takes several 
object files and creates one. Some tool is currently making all those .lib 
files that "bjam -sTOOLS=vc7.1 install" currently makes (26 .lib, 10 .dll).
If Microsoft's tool doesn't do the job (and I'm beginning to suspect it 
won't) then I guess I am volunteering to create such a tool. Or modify the 
"install" portion of the bjam script currently extant.

>Compiling all source files and adding them to a single library looks like
>solution, but really isn't. What if single source does not build with any
>specific compiler? You get no library produced at all.

or you get a library w/ some components missing.

> > > > 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."
>
>I really can't understand why it's needed to use *that* much strong words 
>when
>discussing a question if some file should be just copied to another one with
>a different name!

have you ever worked on Windows and tried to make stuff? We have enough 
problems without adding new silliness to the mix.

I don't understand the reluctance to fix "install" so that no further work 
is necessary.

>- Volodya

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