From: Michael Stevens (Michael.Stevens_at_[hidden])
Date: 2004-06-09 05:40:36
> 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.
I fear the 'no <toolset-gcc:version> feature at all' makes the toolset
implementation rather nasty. 'intel-linux.jam' is simple as it can use
flags intel-linux CONFIG_NAME <toolset>intel-linux-$(version) : $(name) ;
gcc.jam has all the nasty
If you see a better way to do this please don't waste too much time explaining
it to me! I'm just looking at simple solutions.
> 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.
> > 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.
I guess it depends on if you thing "-default" is confusing or a nice bonus!
And of course whatever you think results in the least complexity.
All the best,
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