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