From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-02-09 03:18:56
On Friday 04 February 2005 19:13, Pedro Ferreira wrote:
> >>> 3. Allow the user to say that <toolset>msvc
> >>> is valid, without initializing the toolset.
> >> I like #3. It seems to be the cleanest of your proposals. In fact I
> >> think that all toolsets shiped with BB2 should be valid by default.
> > This would be great. But I dont think that *automagically* scanning all
> > toolsets would be a great idea.
> >> The same goes for the <os> feature that has the same problem.
> > I'm +1 for an explicit list of "configured" values for <toolset> and
> > <os>. So bjam can check for syntax errors.
> In principle, I agree but how does one implement it? Hardcoding a list
> of supported OSs and toolsets?
> Looks a bit awkward... but I think it's better than the other approches.
So, everybody prefers #3. Now it's time to express my opinion.
I think we absolutely need #2 to fix
This means that the *recommended* way to declare alternatives becomes:
lib a : a_msvc.cpp : when <toolset>msvc-6.0 ;
lib a : a_vc7.cpp : when <toolset>msvc-7.1 ;
I think it's acceptable, given that alternatives are not very common. It's
also desirable to retain the existing syntax:
lib a : a_msvc.cpp : <toolset>msvc-6.0 ;
lib a : a_vc7.cpp : <toolset>msvc-7.1 ;
The question now how to validate the features. The problem only arises for
<toolset> and <os> --- which can have unbounded set of values. We also have
this problem for STLport -- I can put <stdlib>stlport-4.5-hostios in the
I still like approach #1 -- don't validate such features. Historically, many
checks in V2 ended up being nuisance -- for example link-compatibility and
"unused sources". For this case, we'd need a new rule, say:
allowed-value toolset msvc ;
and document/test it. Just not validating some features is simpler. And if you
mistyped the condition, you will catch this during testing -- when the right
alternative is not selected, so the value of V2 check is small.
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