Re: [boost] <boost/config.hpp> violates OCP and SDP

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]>
[snip]
>>In other words, it is possible to use the following file
structure:
>>
>>     boost/config/xbox_msvc/boost/config.h
>>     boost/config/dreamcast_mwcw/boost/config.h
>>     boost/config/w32_msvc/boost/config.h
>>     boost/config/x86_linux_gcc/boost/config.h
>>     boost/config/.../boost/config.h
>
>>I independently developed this technique from first principles in
1999 and
>>we have been using this solution in our own libraries since then
with good
>>results. I recall observing that at least STLPort did something
similar at
>>some point.
>
>Yes, we switched STLPort to something like that at my urging years
ago. But
>platform-specific configuration files are still #included from a
central
>file. While not as strictly isolated as the scheme you propose it
is
>slightly simpler for users and might be a good compromise for
boost.
>
>Anyway, your approach is the most correct one. The only question is
whether
>issues of backward compatibility and minor issues of usability mean
that we
>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
personal preferences.

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
my proposal:

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.