|
Boost : |
From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2001-05-27 15:21:28
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.
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.
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.
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.
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.
As a historical remark, config.hpp was meant as a simple solution
to the given problem, without introducing lots of files and the
associated management hassle. It could well be that it's now time
to move to different scheme.
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.)
Jens Maurer
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk