Re: [jamboost] Toolset configuration question

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-06-09 03:50:16

Hi Michael,

> > I'd like to finally settle the question that Michael raised some time
> > ago. Briefly, given
> >
> > using gcc ;
> > using gcc : 3.3 : g++-3.3 ;
> >
> > it is not clear if default-configured gcc is the same as gcc 3.3, or not.
> > This might cause a problem for user, since he can build the project twice
> > without need, and it causes some complexity for toolsets.
>
> Actually the problem is slightly worse given the existing 'optional'
> definition of the version parameter for the gcc toolset. If we have only
> one gcc toolset definition in the configuration thus:
> using gcc : 3.3 : g++-3.3 ;
> It can be built as expected as either 'gcc' or 'gcc-3.3'. Unexpectedly
> however this results in building of two separate build targets (in two
> separate directories) as you noted above.

Yea :-( 

> > Here's what I propose: each "configuration parameter" of toolset should
> > be either specified on all calls of the "using" rule, or omitted in all
> > the calls. The rationale is: first time user can invoke "using gcc ; "
> > and it will work. Advanced user, who wants to configure several version,
> > probably knows the version number of default "gcc" as well, so it's no
> > problem for him.
>
> Agreed "using gcc ;" is nice for new users. I think it is logical that it
> defines the default tool name on the default path with default options.
>
> > I plan to introduce auxilliary funciton to call for this rule
> > automatically, but that's implementation issue.
>
> I was hoping there was a simpler solution to this problem that I had been
> experimenting with. As with the new intel linux toolset the prerequisite is
> that the version parameter be mandatory. If we have the following
> configutation
> using intel : 8.0 ;
> then we can build the actual target named 'intel-linux-8.0' interchangeably
> by invoking an of the four targets 'intel-linux-8.0', 'intel-8.0',
> 'intel-linux', or 'intel'.
> This is very nice!

Agreed ;-)

> At the moment this new method has two problems.
>
> Firstly 'using gcc ;' would be an error as the version parameter has not
> been specified. My solution to this was to make the 'using' rule fill in
> the version parameter with a default where it is not specified. That is
> gcc.init( "default" ) would be invoked in this case.
> This has one draw back. The build target (and therefore the paths
> generated) will be called 'gcc-default', this may or may not be confusing
> for a new user. 

I think this may be confusing and will make the path names even longer.

> This could be improved by either 
> a) thinking of a better name instead of "default"

I'm afraid this is still confusing.

> b) using "" for the default case an surpessing the trailing '-' in the
> target path. This seems overly complex to me however and may result in
> confusion later!

I agree to you. I think we should be able to define the subvariant the first 
time user specifies the version. So, if you have

using gcc ;

then there's no <toolset-gcc:version> feature at all. This means no added path 
elements.

If you have 

using gcc : 3.3 ...
using gcc : 3.4 ...

the <toolset-gc:version> feature will be declared during first call to 
gcc.init. The feature will not be optional, so if will always have the value 
of either 3.3 or 3.4, eliminating the problem you've described.

> The second problem is that the version parameter is currently not checked
> for uniqueness. Therefore if we configure
> using intel : 8.0 : 'namea' : 'compilea' ;
> using intel : 8.0 : 'nameb' : 'compileb' ;
>
> no error is detected. Building 'intel' results in a command line with all
> parameters concatenated! 

Right.

> I have not developed any solution to this but it 
> would be nice if it was handled by the 'using' rule automatically.

I think "using" can't handle this. The problem is that there are some init 
parameters which identify compiler (version) and some which provide 
additional information (paths, setup scripts). The combination of the primary 
parameters which be unique in all "init" class, but only "init" knows which 
parameters are primary. So we'd need another helper rule to check for this, 
and call this rule from every init rule.

> With this definition of version
> using gcc ;
> using gcc : 3.3 : g++-3.3 ;
> can be invoked as
> 'gcc', 'gcc-default', or 'gcc-3.3'
> with the first to building the 'gcc-default' target and the last the
> 'gcc-3.3' which seems nicely logical.

I'm still not sure we can cleanly make this work -- without either "-default" 
in target names or additional complexity.

- Volodya