David Abrahams wrote:
So, can you spell out what that means? When I define BOOST_DETECT_OUTDATED_WORKAROUNDS, what would the behavior be?
Warn if the same compiler is in use and BOOST_TESTED does not match. On second thought the proposed interface is still too complicated and not exactly perfect yet. However, I'll try to explain why I think that something in this direction could be quite useful: The current BOOST_TESTED_AT assumes that a higher version number of a compiler implies a later release date or integration with Boost. Looking at e.g. VisualC-embedded or Borland BuilderX/Kylix it isn't necessarily the case. Further, patch submitters often have more than one version of a particular compiler around so we could allow to express that a workaround has e.g. been tested with version two and three and version three does not require the workaround. If BOOST_DETECT_UNTESTED_WORKAROUNDS is defined we would get a warning for compiler versions that have not been explicitly marked as tested. So if Boost is ported to a new version of a compiler we'll see all the workarounds in question, regardless whether the version number is the highest around. For regression testing (and the officially supported compilers respectively) we'ld always want to define that macro so insufficient testing of a fresh patch shows up in the regression summary. Regards, Tobias