|
|
Boost Testing : |
From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2006-12-16 16:29:20
David Abrahams writes:
> Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
>
> >> >> Because instead of having a single file that's says that versions
> >> >> you have configured and how,
> >> >
> >> > Sorry, I don't see why I should be required to write a file that says
> >> >
> >> > using msvc : 7.1 ;
> >> >
> >> > instead of simply being able to request the same in the command line.
> >>
> >> I would even suggest that user-config.jam use full paths to
> >> compilers.
> >
> > If our auto-configuration code is _that_ unreliable, then we shoudn't
> > advertise this functionality. But seriously, surely we can do better.
> > If Python's distutils can do it, so can we.
>
> It's not a matter of being unreliable. The question is whether it's
> conservative or liberal in finding tools. For the newbie user, we
> really want to try hard to find something. For the regression
> report, we really want to make sure the reported version number
> matches the actual toolset found.
Uhmm, I think we should try hard to find what user requested, newbie
or otherwise, and fail if we couldn't. Somehow I doubt a newbie user
would appreciate an introduction to Boost in the form of a debugging
session devoted to nailing down the fact that
"boost_regex-msvc-7.1-mt-d-1_34.lib" was actually built using MSVC
8.0.
> There's also the matter of historical precedent. In the past we
> didn't have such sophisticated configuration capabilities (e.g. the
> SHELL rule), so falling back to using what was in the PATH was a
> necessary last resort. Now we can even verify that the version number
> on the toolset we find in PATH matches the version number specified by
> the user -- the Python toolset does that, for example.
Understood.
> So, yes, we *can* do better, and we *should*. Do we have to do that
> much better before we release 1.34? Probably not, IMO.
Agreed! WRT 1.43, I was only questioning the "--toolset" form not
working for the "cw-8.3/runtime-link=static" argument.
-- Aleksey Gurtovoy MetaCommunications Engineering