Boost logo

Boost-Build :

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
>> is the more common case these days but I couldn't think of a good suffix
>> single threaded).


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

-- grafik - Don't Assume Anything
-- rrivera (at) - grafik (at)
-- 102708583 (at) icq


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at