From: Rene Rivera (grafik.list_at_[hidden])
Date: 2003-11-28 12:25:52
Victor A. Wagner, Jr. wrote:
> OK, point by point....
> At Friday 2003-11-28 03:20, you wrote:
>>Victor A. Wagner, Jr. wrote:
>> 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
> 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.
1. I'm well aware of the AmigaOS solution... My 4000T and 2000 are still
2. Versioned linking and loading is available in ELF, which is used in many
Unices, BSDs, and Linux.
3. Any versioned linking or loading, on any platform (some minor exceptions),
requires that you have the version as part of the name of the library so that
old programs still have a chance of functioning, as multiple versions can
exist without collision.
>>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.
Yes, making directory changes in your projects or system is conscious step.
It's no different than making the changes for the names, other than in number
of changes made.
>>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"?
Yes! And that is something that will get done eventually. But in BBv1 it's not
as easy as it is in BBv2 ;-) I didn't think I needed to point out the
obvious.. I thought the discussion was about removing the version number
entirely, so excuse my misunderstanding if that wasn't the case.
..But it is something that is very easy for a comprehensive installer, or
updater. For example RPM, DebPKG, BSD/ports, etc.
>>>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.
>>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
> reading the command:
> bjam -sTOOLS=blahblah install
> leaves one with the impression that it has actually installed something
> useful on the system.
It is useful, it's just not as versatile as you (and me) would want it to be.
> 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
Frankly, you did the suggesting in a tone that I took affront with. But I
understand, and forgive :-)
> 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
Like all technology having something that works now, and will be improved
later, is better than having nothing now, and something that might work much
So creating a script that copies the files to the names you prefer would work,
>>>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.
Like all things in Boost, we are about making a solution that works for many
platforms. The solution in this case does a reasonable job of working on all
platforms, including VMS which is the hardest to deal with. But no, it's not
as convenient as implementing a different solution for each platform.
>>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.
Yes the "tool" you refer to is the compiler/linker. But it only transforms
from .obj-s to .lib. It will not transform .lib-s to a .lib. Something which
is possible in Unix/Linux/BSD.
>>>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
No, I was expecting people to come up with the obvious copy or rename files to
your liking solution.
>>I really can't understand why it's needed to use *that* much strong words
>>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.
What I don't understand is how you dealt with previous versions of Boost.
Perhaps you can explain, with examples, how you use and distribute programs
that use Boost over different versions. How do you deal with users having
multiple programs that use multiple versions of Boost libraries? How do you
install them? How do you upgrade them? -- You can replace program with library
above and answer the same questions.
> I don't understand the reluctance to fix "install" so that no further work
> is necessary.
It's not a reluctance to fix it. It is not broken. It's just not currently a
complete solution to all problems. That takes time and more importantly
-- -- 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