Re: [jamboost] Improving BBv2 versioned toolsets

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-11-03 03:39:25

Hi Michael,

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

That would be great.

> Actually gcc.jam is even worse with its $(NAME:E=g++) mechanism.

gcc was the first toolset, so I used the first trick that worked. It would be 
great to have this cleaned up!

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

I agree to you. The question is what the default value would be? As Dave 
mentioned, if you only have 

using gcc : 3.1 ;

then the default version should be 3.1. For 

using gcc ;

the default version might be "unspecified". Still, what are we to do for the 
case of:

using gcc ;
using gcc : 3.1 ;

? 

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

The code which adds default properties in in targets.jam, in 
'main-target.generate' rule. There's 

p = [ $(p).add-defaults ] ;

which does the trick. In order to change default value of the version feature, 
you'd need 'feature.set-default' rule.

> 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 doubt that -- the property-set.empty is not special cased -- the 
'add-default' call above does not care if user requested empty property or 
there's something else.

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

If we could write generic code which will work for all tools, that would be 
excellent! Of course, even if it's not possible, uniform handling of version 
by all toolsets is good thing.

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

True, that's confusing. By setting default value of version this will be 
fixed.

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

Yea, I don't see any problems either. If you need further help with the code, 
don't hesitate to ask. Moreover, if you find some code which is 
undercommented or unclear, feel free to point out. Eventually, I'd have to 
stop developing new features and start cleaning up the code, in preparation 
for 2.0 release.

- Volodya