Re: [jamboost] Improving BBv2 versioned toolsets

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-29 01:45:03

Hi Michael,

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

> 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

<toolset>gcc 

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

msvc

and 

msvc-6.0

The build properties for each main target will include

<toolset>msvc

and 

<toolset>msvc <toolset:msvc-version>6.0

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

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

- Volodya