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

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-05-27 09:06:13

----- Original Message -----
From: "Vesa Karvonen" <vesa.karvonen_at_[hidden]>

> 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.

Yes.

> 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)

Good.

> 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.

Great, I think that solves the usability problem!

> 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.

Great, I think that solves the backward-compatibility problem!

> ...
>
> 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.

Well, I like your proposal very much. Would you care to upload an
implementation of it to the boost files area? Assuming that it works and we
don't hear significant objections, we can check it into CVS in the near
future.

-Dave