================ Comment at: lib/Driver/Tools.cpp:6721 @@ +6720,3 @@ + + // FIXME: If we've put clang-cl as cl.exe on the path, then we might have a problem now :/ + const char *Exec = ---------------- Reid Kleckner wrote: > Hans Wennborg wrote: > > Reid Kleckner wrote: > > > That seems problematic. You could use sys::fs::equivalent() to skip a > > > path if it's the current executable, but we'd have to sink that into > > > GetProgramPath(). > > On the good side, we're not passing /fallback through to the second > > invocation, so we don't get stuck forever :) > > > > On the bad side, I don't think checking sys::fs::equivalent() would work, > > because the cl.exe on the PATH could be a copy of clang-cl.exe, as in the > > case of the current VS integration :/ > > > > It seems that automatically looking for the "true" cl.exe could get pretty > > messy. > > > > What do you think about having an option, like /fallbackcommand <foo>? > > Ideally, the VS integration could set this automagically, and it would also > > be useful for testing (we could set this to "echo" or something and test > > the actual execution of the fallback). > I agree it could get messy, but I think there's an important common case, > which is where the currently running compiler is the cl.exe on PATH, and the > next cl.exe on PATH is MSVC. That's the set up we use for VS project files, > so it's pretty important for users. I'm fine handling that as a followup, > though. Ah, yes. I was thinking we'd need to have a general "is cl.exe really clang-cl.exe" check, but that's not what we need for this case. I'll address this in a follow-up.
http://llvm-reviews.chandlerc.com/D1711 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
