[cfe-dev] Extra #defines for Windows SDK 6.0a/VS2008

[Francois Pichet]

Hi,  I would like to restart this discussion.

Lately I have been submitting patches to address MSVC compatibility
issues. The way
I am working is I created a test.cpp file that #include all the header
files shipped with
Visual Studio 2008 (~1600 files).

I then excluded the .h that aren't designed to be included directly
and commented out
the header files that are heavily templated (mostly mfc/atl/stl
headers) because clang
cannot deal with them.

So I am left with ~1200 header file. I estimate that clang is 5-6
patches away (2-3 weeks)
from being able to compile these 1200 header files without error using
clang -fsyntax-only.

The thing I plan to do after those 5-6 patches is to slowly un-comment
the templated .h I excluded
1 by 1,analyze why clang cannot deal with them and submit patch to
resolve the problems.

My primary interest is doing that is to be able to use clang code
analysis functionalities on
Windows code (including MFC, ATL, COM, GUI). I am interested in
bringing the CLangChecker
lib to work with MSVC  but I also plan to use clang to write custom
code analysis modules.
(For example using clang to check if code meet a custom corporate C++
coding standard).

Doing this requires clang to parse MFC/ATL/COM/GUI code.
To me, this is an interesting goal.

So here is my question: If I start submitting patches to adapt clang
to parse anything
MSVC can parse (MFC/ATL/ETC), is that something acceptable to the clang project?



>
> Guys, it depends on what the goal is here.  If the goal is to replace MSVC and build anything it does, then we have to emulate a huge number of their bugs as well as their features.  I don't think this is an interesting goal.
>
> If, instead, the goal is to build portable command line apps on windows, then things get more tractable.  This defines away things like MFC for example.
>
> -Chris