[wasabii]

A target triple is whatever clang makes of it, so the SDK no longer reads
meaning into the string. A new ResolveClangTarget task asks clang, in
parallel: how it normalizes the triple, which macros it predefines for it,
and, by compiling an empty file, which object file format it produces.

• Output names follow the object format: COFF is named as on Windows,
  Mach-O as on Apple, everything else as on Linux. UEFI, for one, now gets
  .obj and .lib, though its triple says nothing of Windows.
• The MSVC environment, which decides whether a .pdb is expected, is told
  by clang defining _MSC_VER.
• ClangTargetTriple, ClangObjectFormat and ClangTargetIsMsvc are set for
  the rest of the build, and GetOutputItem reports the first two. Setting
  ClangObjectFormat or ClangTargetIsMsvc in the project overrides clang.
• A triple clang cannot build for fails the build with ICLANG3001 and what
  clang said; Clean and design-time builds still work.
• Answers are kept in memory for the build process and in obj/ for later
  builds, keyed on the compiler, its timestamp and size, and the triple.
• The naming properties are now set by the ResolveClangTarget target
  rather than at evaluation, and the string-matching ClangTargetOS is gone.
• The executable test exits through ExitProcess, so the loader's threads
  no longer keep it running past the test's wait.

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}