[cfe-commits] Windows driver cleanup (or however you want to call it)

[Nikola Smiljanic]

> Well the logic for this should be the same as the one in the batch
> files for each platform target.

The logic in the batch file requires the user to run the appropriate
batch file. So how would you implement this logic without the user
running it?

> Using the triple to do this feels wrong. Whether using the MinGW
> headers or MSVC headers, the platform is still Win32.

I was just interpreting the source code, where Win32 is the VS triple
and Mingw has its own. Maybe the first one should be called MSVC or
something like that, but I digress. How does this feel wrong when
triples exist for this very reason, for clang to decide which
ToolChain to use?

> I think removing the VS and Windows SDK detection from the driver is
> not the best approach for long term support.

The way I see this is:
if there is a notion of active sdk/compiler, then detecting it makes
sense as it won't surprise the user,
otherwise we shouldn't try to guess.

I'm not sure if this stands for sdk? I think the system does in fact
have one active sdk and stores this in the registry. But I do know
that there is no such thing as active VS compiler (unless you have
only one installed).

> Users of the driver
> library (like in IDE integration) will want Clang to automatically
> find the correct include paths and having to ask an user to run a
> messy batch file that sets some environment vars just doesn't seem
> like a very robust solution.

Since this is a VS driver it makes sense to follow VS conventions, and
this is exactly how the IDE works, it alters the environment before
invoking cl.exe. Why should clang work any differently?

> Instead I think we should keep the same approach and just improve it
> to handle what is needed. It would be good to see some discussion on
> what combinations of system headers (MinGW / Windows SDK) and library
> headers (libcxx / libstdc++ / MS) should be supported, so we can
> design the code accordingly.

I agree.