Re: [jamboost] Improving BBv2 versioned toolsets

From: Michael Stevens (Michael.Stevens_at_[hidden])
Date: 2003-10-31 04:04:19

Hi Vladimir,

Thanks so much for your input!
> 
> They certainly are not clean. They were introduced in the times where
> subfeatures --- such as toolset version --- was not allowed to have default
> value.
> 
Oh.. I hadn't noticed that default value had been added. I will have to 
look into that.
> > 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.
I am trying to put together patchs to at least clean up gcc and msvc.
Actually gcc.jam is even worse with its $(NAME:E=g++) mechanism.

> 
> > 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>
Oh I agree with the guy wearing the hat! Best way to deal with this is 
keep the strict signature but to make toolset.jam generate a default 
value for the version parameter in this case.
This would mean the every <toolset>xx would have a <toolset:xx-version> 
defined.

> 
> > 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.
This is the section of code I am trying to find. My plan was to generate 
the default property values from the first declared toolset including 
its version. For this I require the previous change which enforces the 
existance of a version.

In fact it may be simpler to simply always invoke the generation 
procedure with with this combined <toolset>xx and <toolset:xx-version> 
build properties. May even speed up the code as it would no longer have 
to special case the 'property-set.empty'.

I will have to find the code first however!

> 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).
I fairly sure I understand this mechansim. My secondary aim was to avoid 
this complex handling the individual 'tool' code completely.
> 
> > 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...

I have an even simpler problematic case with the current implementation. 
In a very round about way this is what I was trying to explain previously!
If there is only a single configuration for gcc thus:
using gcc : 3.3 ;

It is possible to invoke a build as
bjam
or	bjam gcc
and
bjam gcc-3.3
The first two are identical. The last produces the same code but in a 
different target directory!

Hope this all makes sense. I will look at the code myself. I think I am 
correct in assuming there is no fundemental reason why the change would 
not work.

Michael