> What we have right now in the driver sucks for various reasons. Code for > handling multiple versions of VS is very complex and possibly incorrect.
The current registry code is indeed a little dirty, but see the refactored version in my patch which makes it a little easier to follow. If it is incorrect then it should be fixed to follow the same approach as in the VCVarsQueryRegistry.bat file. Please report any bugs. > How do you select the right VS (latest version?). Also how do you get the > include paths, these depend on the target. How do you find the right > link.exe, and so on. Well the logic for this should be the same as the one in the batch files for each platform target. > My assumption is that Win32 in the triple means "standalone Clang that uses > headers and tools provided by VS to target the Windows platform". Hope that > mingw never plays a role in here and always uses its own triple? Using the triple to do this feels wrong. Whether using the MinGW headers or MSVC headers, the platform is still Win32. Instead we should model the possible libraries in the driver, and provide switches to change between them. The patch I attached starts some of that work. > What do you think, have I missed anything? I think removing the VS and Windows SDK detection from the driver is not the best approach for long term support. 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. 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
