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
>> 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.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:
>> 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> 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) acm.org - grafik (at) redshift-software.com
-- 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