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

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2001-05-27 16:30:02

From: "Jens Maurer" <Jens.Maurer_at_[hidden]>
> Vesa Karvonen wrote:
> > 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.

I'm currently working on the new <boost/config.hpp> system.

Here are my current notes:
- I defined the directory boost/config for the compiler dependent external
configs.
- I chose the names for the external config directories based on the
primary macro that is used for identifying the implementation.
- The original <boost/config.hpp> was, among other things, rather
inconsistently indented. The new dispatching config should be much easier
to read and maintain.
- There was one preprocessor statement in boost/config.hpp that did not
correctly start on the first column.
- The last compiler independent part of the original <boost/config.hpp>,
was moved to a separate header <boost/config/common_config_suffix.hpp>,
which is now included by each of the compiler dependent external configs.
- Also moved the BOOST_VERSION to common_config_suffix.hpp.

Here is my current TBD list:
- Move #define documentation to another file
- Update config documentation
- Test
- Review
- Wait overnight
- Review again

NOTE: It is getting late (0:26) so it will take at least 15 hours for me
to get the system ready.

> Note that the situation is more complex than this.  For many platforms,
> there are quite orthogonal compiler/standard library configurations.
> For example, STLport is available on lots of platforms, so the
> workaround configuration STLport could be separated in its own
> section/file.

A quick check of the headers using Search&Replace reveals that:
- STLPort/SGI_STL_PORT/STL is explicitly referred to in
  - config/common_config_suffix.hpp
  - config/gnuc/config.hpp
  - config/msc_ver/config.hpp
  - config/icl/config.hpp

I will not attempt to remove the duplication at this point. Removing the
duplication should be easy, as long the resulting system can be tested on
all compilers. Actually, I can access all of the above (gnuc, msc and icl)
compilers.

> Also, the current config.hpp works for unknown, but fully conforming
> compilers/libraries out-of-the-box.  Giving an #error for these
> seems inappropriate, because it requires actually detecting all the
> platforms, which I would rather avoid.  The default for boost on
> a new platform would be not to work, without even trying.

This is one of the issues I ran into just before receiving your e-mail. I
will use the convention you suggest. In other words, if the compiler is
unknown, then boost/config.h will not issue an error.

> Having a "dispatching config.hpp" would not solve the excessive
> recompilation problem per se, but would allow avoiding it by
> configuring the compiler #include path according to the platform.

Most fortunately, your analysis is not entirely conclusive. The
dispatching config does indeed significantly reduce the need to modify the
boost/config.hpp file. Consider the following (preliminary) contents of
boost/config.hpp carefully. You will notice that there is very little, if
any, need to modify boost/config.hpp in the future.

//  Edison Design Group front-ends
#if defined(__EDG_VERSION__)
#  include <boost/config/edg_version/boost/config.hpp>
#endif

//  Compiler-specific checks
//  Compilers are listed in alphabetic order (except VC++ last - see
below)

//  GNU CC (also known as GCC and G++)
#if defined __GNUC__
#  include <boost/config/gnuc/boost/config.hpp>

//  Kai C++
#elif defined __KCC
#  include <boost/config/kcc/boost/config.hpp>

//  SGI MIPSpro C++
#elif defined __sgi
#  include <boost/config/sgi/boost/config.hpp>

//  Compaq Tru64 Unix cxx
#elif defined __DECCXX
#  include <boost/config/deccxx/boost/config.hpp>

//  Greenhills C++
#elif defined __ghs
#  include <boost/config/ghs/boost/config.hpp>

//  Borland
#elif defined __BORLANDC__
#  include <boost/config/borlandc/boost/config.hpp>

//  Intel
#elif defined __ICL
#  include <boost/config/icl/boost/config.hpp>

//  Metrowerks CodeWarrior
#elif defined  __MWERKS__
#  include <boost/config/mwerks/boost/config.hpp>

//  Sun Workshop Compiler C++
#elif defined  __SUNPRO_CC
#  include <boost/config/sunpro_cc/boost/config.hpp>

//  Microsoft Visual C++ (excluding Intel/EDG front end)
//
//  Must remain the last #elif since some other vendors (Metrowerks, for
//  example) also #define _MSC_VER
#elif defined _MSC_VER
#  include <boost/config/msc_ver/boost/config.hpp>

//  An unknown compiler
#endif

> I run the full boost regression tests rather often.  In general,
> config.hpp does not cover all of the trouble with a given compiler
> or library.  Often, specific workarounds have to be crafted into
> the failing headers (e.g. iterator.hpp), which sometimes leads to
> a new #define for config.hpp.

In the future, those changes will hopefully be made into compiler specific
config.hpp files. Those changes will cause all code to be revisited on the
compilers that need the #define, but not on others. The very long list of
comments in the config.hpp file that describes the #defines will be moved
to another file. Therefore it is significantly less likely that the
boost/config.hpp would have to be changed.

> Finally, the proposed directory structure is rather deep and
> contains several one-entry directories.  (There used to be a
> draft boost directory structure document somewhere, but I can't
> find it right now.)

True. It takes some extra structure to invert dependencies. In
contemporary OO design, you define an interface. This extra interface
would not be necessary in a structured design. Unfortunately, with a
structure design, you'd end-up with undesirable dependencies.

Similarly, using the preprocessor for dealing with platform differences,
you need to define an interface for including the config file. In Boost
this is defined as:

    #include <boost/config.hpp>

This implies that using a traditional file system, each "config.hpp" must
be in a "boost/" directory. If you don't mind breaking existing code, it
is possible to change the above interface.

Anyway, I'm open to better solutions, and will reserve the right to change
my mind without notice.