From: John Maddock (john_at_[hidden])
Date: 2003-11-19 08:11:04
> >> I guess that's their problem, since AFAICT we're unable to properly
> >> detect all the conditions which say whether wchar_t is supported.
> >Though I appreciate any effort to create a new, modern and
> >reliable build system I strongly disagree here.
> >A build system that has no autoconfiguration property like
> >GNU-autoconf/-make/-header kicks us right back to the
> >middle-age where we fiddled around with imakefiles and
> >other design problems that hinder plug'n'play.
> >If I decide to have this or that flag on, I expect
> >no library in use to bail out, but to build smoothly.
> That's a nice sentiment, but how do you propose Boost config (or any other
> configuration system) could reliably detect wchar_t status for the Intel
> It isn't good enough to pre-analyze the compiler via a trial compilation,
> because compiler options may have changed when the real compilation is
Also we already have a configure script to patch up the headers for
"unsupported" platforms/compilers, but that won't work for Intel on
*Windows*, which is the problem case we're talking about here (and please
don't tell us to use Cygwin to run the script - that's only partially
compatible with windows compilers (looking for external libraries doesn't
work for example), and not at all compatible with some (Borland's compiler
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk