Subject: Re: [boost] [build] How to use with clang on windows?
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-03-26 06:52:12
On 3/26/2016 12:58 AM, degski wrote:
> I don't really get what this means, could you please elaborate? What does
> "to use" and "the clang compatibility mode in the VC++ 14 IDE" mean. And
> what is "the preprocessor problem"?
The VC++ preprocessor is not a C++ standard conforming preprocessor.
Both Boost PP and Boost VMD perform various tricks to get the VC++
preprocessor to mostly work with those heavily macro based Boost
libraries. This working with VC++ in Boost PP and Boost VMD depends on
identifying the VC++ compiler. Many other Boost libraries use Boost PP
so using those other libraries with VC++ are affected by all the
workarounds in Boost PP to get the non-standard VC++ preprocessor to be
workable with Boost PP constructs.
The clang build which targets VC++ on Windows, as opposed to the clang
build which targets mingw(-64)/gcc on Windows, 'emulates' the
non-standard VC++ preprocessor so it can compile Windows API headers and
VC++ header files. Exactly what VC++ preprocessor 'bugs' it emulates and
how successful this emulation is I do not know, but I know it is done
because I was told of it in the clang developer forum and I encountered
a clang targeting VC++ preprocessor 'bug' which was explained to me as
an emulation of VC++.
It was hard enough work for Paul Mensonides to get the VC++ preprocessor
to work with Boost PP and it was hard enough work for me to get the VC++
preprocessor to work with Boost VMD that neither I nor, I assume, Paul
wants to go back and figure out another set of preprocessor 'bugs' to
get clang targeting VC++ to work with those libraries. For all I know
clang targeting VC++ may indeed work with those libraries if the
libraries pretend that clang targeting VC++ is VC++ for the intention of
those libraries. Since I have been basically taking care of Boost PP and
since I am the author of Boost VMD I have not tried clang targeting VC++
as VC++ in those libraries since I do not want to be tasked with fixing
another set on non-standard C++ preprocessor bugs for another compiler
if it does not work.
I made a suggestion to the clang developers that there 'emulation' of
the non-standard VC++ preprocessor in their clang targeting VC++
implementation should be configurable so that when the compiler is not
dealing with Windows API and VC++ header files it can be turned off and
clang would then be the same C++ standard conforming preprocessor as it
is with clang targeting mingw(-64)/gcc and clang on Linux and on the
Mac. The suggestion was rejected. After that my interest in running
clang targeting VC++ on Windows ended.
Unless you have dealt with it personally you cannot know how difficult
it is doing the sort of preprocessor programming which Boost PP does and
Boost VMD does with the VC++ preprocessor. Being asked to work with
another preprocessor which 'emulates' the VC++ preprocessor in various
unknown ways is not a task I wish on anybody.
I fully understand why the clang developers in their efforts to have
clang on Windows work with VC++ had to 'emulate' the non-standard C++
preprocessor to work with Windows API and VC++ header files, since
enough quirks in those header files have depended on the non-standard
VC++ preprocessor. But propagating that non-standard preprocessor
behavior to all preprocessor processing is IMO a major mistake,
especially as the normal clang preprocessor is very good and C++