From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-29 01:45:03
> I have been looking at ways to improve the current way that toolset are
> versioned in BBv2. I have a lot of different compilers versions so this
> is important to me.
> Firstly all the toolset definition have to work around the 'unspecified'
> default values problem. They all do this in a variety of complex ways.
They certainly are not clean. They were introduced in the times where
subfeatures --- such as toolset version --- was not allowed to have default
> Looking at the way toolsets have to handle this I think things could be
> significantly simplified if toolset versions were enforced.
I tend to agree. E.g. msvc.jam has some conditional to handle case where
version is specified, and not specified.
> That is to
> say toolsets always were defined with the following init signiture.
> rule init ( version : name ? : path ? )
<user hat on>
That's too strict. I would like to write
using gcc ;
and have it work, no matter what the version is.
</user hat on>
> For this to work the current way toolset build requests are invoked
> would have to change. Looking at the current code there is already
> special handling. The 'unspecifed' toolset is invoked specifically at
> line 157 of build-system.jam
> for local t in $(targets)
> local g = [ $(t).generate [ property-set.empty ] ] ;
> virtual-targets += $(g[2-]) ;
No, you misunderstood that line. When no properties are specified on the
command line, we pass empty set of properties to all requested
"metatargets" (projects, main-targets). When a main-target is generated, it
adds default property values. So, it you have gcc as the first declared
toolset, and it has no version, each main target would add
to the list of properties, but no version property at all.
> It would be necessary to change this so the toolset is invoked with the
> first (or only) specified version. Sadly at this point in the code the
> trail goes cold for me. I'm unable to find where the 'unversioned'
> properties are generated by the special value 'property-set.empty'.
As I've indicated above, "unversioned" are not generated at all.
Consider two possible build requests
The build properties for each main target will include
respectively. The msvc.jam has a line (134) in the form
flags msvc.compile .CC $(condition) : $(prefix)$(compiler) ;
which was executed when initializing 6.0. So, in the second case, this line
will cause specific value of ".CC" in compile action. In the first case, you
won't have any specific value of ".CC" in compile action, so bjam will look
for value of ".CC" which is global in "msvc.jam" module. That value is set on
line 114, with
.CC = $(prefix)$(compiler) ;
Uph... complex to explain at least. Feel free to ask for more clarification
(they might turn out to be unneeded, if we change this scheme).
> Enforcing versions would have a further significant side effect. With
> some toolsets it is currently possible to invoke the first definition
> both using the default 'unspecified' version and with a specified version.
> Both invocations result in the same code (same property-set) but their
> target directories are named differently. This has often got me into
IIUC, the problematic case is
using gcc ;
using gcc : 3.3 ;
using gcc : 2.95 : g++-2.95 ;
when default gcc is already 3.3? I'd don't like banning the first line because
that's the simplest UI. Probably, it makes sense to disallow specifying no
version, when there's other initialization with version? In the case above,
the first line should be removed. 3.3 will become the default version...
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