[PATCH] D146165: docs: add some documentation on Windows SDK search

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd added a comment.

> Looks reasonable I guess - but I think it would be good to mention the env variables INCLUDE and LIB too, for alternative ways of finding the same things - even if it's not strictly the same as what this new section talks about.

Yes, I agree, I did miss that in this.  I don't think that the point is entirely correct though, because `Include` **does** impact the WinSDK lookup.  That means that it is reflective of what the section is talking about.  `LIB` belongs in both I believe as that impacts the lookup for the libraries for both the SDK and Visual C++ tools (for VC Runtime).  Basically, I think that your point is more important than what you were attributing to it and this needs to be further refined for precision.



================
Comment at: clang/docs/UsersManual.rst:4537
+
+    TODO: This is not yet implemented.
+
----------------
hans wrote:
> But isn't this how clang-cl finds stuff when running in a "Visual Studio Command Prompt" / setenv / vcvars or whatever it's called these days?
> 
> I think this would be the most common case for people building from the command line, and I'd suggest perhaps starting the list with this one (I realize they're currently sorted by precedence, but sorting by most common first would also be valid I think).
> But isn't this how clang-cl finds stuff when running in a "Visual Studio Command Prompt" / setenv / vcvars or whatever it's called these days?

No, it isn't, because this is the Windows SDK portion.  The environment variable is for the Visual C++ tools only, the environment based SDK lookup is unimplemented.

Something something complexity something.

This is part of why I structured this the way as I have.  There are two parts of the lookup here, the part dealing with the SDK and the part dealing with the VC++ tools.  Now, it could be argued that this is finer point of detail that most will not care about, and I am concerned that is very much true, but the reality is that there is a bunch of complexity in the lookup and the value in documenting the behaviour is that we can easily lookup how to control the behaviour of the driver.

> I think this would be the most common case for people building from the command line, and I'd suggest perhaps starting the list with this one (I realize they're currently sorted by precedence, but sorting by most common first would also be valid I think).

I think that common behaviour should be listed in prose.  If someone has more than one mechanism in the command line, the resulting behaviour would not match the written one and that can lead to confusion.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146165/new/

https://reviews.llvm.org/D146165