Re: Install, mangled lib names [ WAS; Common Lib Subdir]

From: Rene Rivera (grafik666_at_[hidden])
Date: 2003-08-26 10:45:21

[2003-08-24] David Abrahams wrote:

>"John Maddock" <boost.regex_at_[hidden]> writes:
>
>>
>> 5) Mangled names - I think these needs careful consideration - the
>> problem I have with your scheme (and the incompatible one that
>> boost.regex currently uses for that matter) is that they are too
>> cryptic, I mean what on earth is boost_regex-vc71-gd-131.dll?

Debug build, linked against the debug runtime -- of course I had to look it
up ;-)

>> So I was thinking - don't use a suffix at all for the most common
>> option - and use a unique and hopefully understandable suffix for
>> any other cases:

My goal did include using the minimal suffix for the most common case for
Users (allowing for expectations). Which is using release builds against
release runtimes, single threading. Ex; boost_regex-vc71-131.dll (+lib). But
perhaps the muti-thread variant should be the most common (as you point
out)? Opinions/votes on this are welcome.

>> threading - _mt if it's on otherwise nothing (actually I thinking
threading
>> is the more common case these days but I couldn't think of a good suffix
for
>> single threaded).

"st"?

>> runtime - _srt for static runtime otherwise nothing
>> _dbg - for debug, otherwise nothing
>> .. and so on, which would give us:
>>
>> boost_regex_vc71_mt_dbg_131.dll
>
>Boost.Build uses a similar rule for generating subvariant directories.
>
>> which looks almost comprehensible, well slightly better anyway... on the
>> other hand I worry that this might cause the names to get too long:
>>
>> libboost_regex_vc71_mt_dbg_srt_pydbg_stldbg_131.dll
>>
>> is just about possible (multithreaded, debug, static runtime, python
debug
>> lib, STLPort debug lib).
>
>Yep. I think the answer for mangling is: just give up on readability
>and pick a single letter for each property.

I agree with that. I don't think we can come up with short enough names to
make multiple abreviations useable. And there is a large group of Users
already familiar with single letter tags. For further discussion here's what
I currently do (straight from the bjam source code)...

# Common rules for generating a single stage tag based on the
# variant, build properties, and the toolset used to build.
# To use place this rule name in the requirementes section of
# a stage target.
#
# The tag is constructed as such:
#
# [-<toolset-tag>][-<thread-tag>][-<runtime-tag>]
#
# <toolset-tag> maps to an abbreviated name of the toolset
# and when possible and applicable the version of the toolset.
#
# <thread-tag> "mt" when multi-threading is enabled.
#
# <runtime-tag> adds these single letter tags:
# "s" when static linking to runtime
# "g" when linking to debug runtime
# "y" when building debug-python variants
# "d" when building debug variants
# "p" when building with stlport libraries
#
# The tag added is a <tag><prefix> to allow for additional tags
# in the stage. For example the version tag.
#

PS. I think we can get far with the mostly single letter shorthands, as long
as we document it clearly to Users what the produced libraries mean, and are
for.

-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq