This would have saved me the time I spent figuring out why something
went wrong with the project generation. In my case, the absolute path
shown by this warning would have been overtly invalid because the tool
was failing to infer the source root directory.
Update the property to include the SDK MSI for Windows as we start
adding additional platforms. Update the file name patterns to reflect
the new naming.
There is no guarantee that `cmake` is available in the path. CMake may
be provided through VS or the VS Build Tools, in which case, you must be
in a VSDevCmd environment to invoke `cmake`. This adds quite a bit of
complexity for little gain as the projects will check of the minimum
version required (`cmake_minimum_required`).
* Revert "[Build] Fix swift_build_support tests."
This reverts commit fc2d1b3b23.
* Revert "[BuildSystem] Stop building for i386-watch-simulator (#77692)"
This reverts commit 1ab968d2b6.
This change can't be made without other issues fixed downstream first.
https://ci-external.swift.org/job/swift-main-windows-toolchain-arm64/777/consoleText
```
Error: Program 'python.exe' failed to run: The specified executable is not a valid application for this OS platform.At C:\Users\swift-ci\jenkins\workspace\swift-main-windows-toolchain-arm64\swift\utils\build.ps1:545 char:7
+ & $Executable @Args | Out-Null
+ ~~~~~~~~~~~~~~~~~~~.
```
Enable support for libxml2 on Windows to allow `llvm-mt` to be usable.
This then allows us to use `llvm-mt` as the manifest tool when building
for Windows. Remove the then obsoleted workaround of `-D CMAKE_MT=mt`.
This reduces the dependency on the MSVC toolchain and paves the path to
enabling the use of the manifest tool in SPM.
However, to do this, we end up changing how amd64 is supported too.
Previously, I had tried to keep some meaningful separation between
platform spelling and LLVM spelling, but this is becoming more difficult
to meaningfully maintain.
Target specifications are trivially converted LLVM triples, and the
module files are looked up by LLVM triples. We can make sure that the
targets align, but then the Glibc to SwiftGlibc import breaks. That could
also be addressed, but then we get to a point where the targets set up
by build-script and referenced by cmake begin to misalign. There are
references in build-script-impl for a potential renaming site, but it's
not quite enough.
It's far simpler to give up and rename to LLVM spellings right at the
beginning. This does mean that this commit is less constrained to just
adding the necessary parts to enable arm64, but it should mean less
headaches overall from differing architecture spellings.
