[boost] Re: Re: Recent changes to intel compiler config

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-11-20 11:52:25

Markus Werle wrote:
> Beman Dawes wrote:
>
>
>> 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 compiler?
>>
>> 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 run.
>
> I agree in that the options may have changed.
> Then it's the user's fault of course.
> Maybe I misunderstood what David said.
> I understood that he rejected the build system
> to be able to handle _any_ compiler flag combination I choose,
> but to require some flags to be set (like the one that sets
> wchar_t on windows).
>
>
> If I link to the wrong version which was compiled with different,
> incompatible flags then it's my fault.
> OTOH I wish boost to build automagically when I call
> the "configure CXXFLAGS=<the same flags as in my project> && make"
> even if this removes XXX (e.g. wchar_t) support from the lib.
>
> If I decide not to use this or that feature of my
> compiler by choosing some compiler flag, I do not want to
> be forced to revise this decisison simply because boost
> requires some flags.

I have made this point before. In order to both support native wchar_t and
typedefed wchar_t on VC and Intel compilers, it really is necessary to have
library builds create versions which support either one, preferably with
slightly different final names. I realize that this doubles the number of
possible libraries being built when wchar_t is involved in any way, and
creates a further support headache.

The alternative is to say that Boost only supports native wchar_t and that
to use a particular Boost library one must use native wchar_t when
interfacing with it. While to do this is certainly the right ideal, the
practical reality in the C++ programming world is that of many programmers
are constrained to use the typedefed wchar_t not only to maintain
compatibility with the past, mandated by corporate programming departments,
but also because other 3rd party libraries, with which the programmer must
interface, only support the old non-standard way.