From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2001-05-27 05:16:46
From: "David Abrahams" <abrahams_at_[hidden]>
> From: "Vesa Karvonen" <vesa.karvonen_at_[hidden]>
>>In other words, it is possible to use the following file
>>I independently developed this technique from first principles in
>>we have been using this solution in our own libraries since then
>>results. I recall observing that at least STLPort did something
>Yes, we switched STLPort to something like that at my urging years
>platform-specific configuration files are still #included from a
>file. While not as strictly isolated as the scheme you propose it
>slightly simpler for users and might be a good compromise for
>Anyway, your approach is the most correct one. The only question is
>issues of backward compatibility and minor issues of usability mean
>should do something else.
IMO, backward compatibility and usability are not minor issues, but
change is often necessary to ensure safety, flexibility and
usability also in the future.
I think that we need better names for the approaches than my/your
scheme, because otherwise someone might see this as merely promoting
I propose the following names for the schemes:
- external config (the strictly isolating scheme)
- dispatching config (the STLPort scheme)
- internal config (the current Boost scheme)
IMO, it is necessary to change the <boost/config.hpp> design,
because of the known problems inherent in using an internal config.
The more difficult issue is how it should be done. The following is
All new platforms would use an external config. In case the
detection code in <boost/config.hpp> fails, it should give an #error
that points to information on how to:
- download the latest boost version and
- use an existing external config or
- implement and submit a new external config.
The current <boost/config.hpp> would be supported for the
implementations that it currently supports. When new versions of
implementations become available, they would switch to using an
external config exclusively.
The current <boost/config.hpp> would be changed to a dispatching
config. The dispatch code would dispatch to an external config for
the platform. This way it would be possible for a user to avoid the
problems caused by updates to the current <boost/config.hpp> by
explicitly making sure that the external config is used directly.
An alternative approach would be to support the dispatching config
indefinitely, even for new platforms, but make it sure that it is
always possible to use an external config directly. This would trade
some safety to usability.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk