This was quite brittle and has now been superseded
by swift-xcodegen. Remove the CMake/build-script
logic for it, leaving the option behind to inform
users to switch to using xcodegen instead.
* Rename 'BuildRule to 'BuildEdige' because it is the official term
* NinjaParser to handle 'include' and 'rule' directives
* NinjaParser to handle parse "rule name" in 'build' correctly
* Make variable table a simple `[String: String]` and keep any bindings
to make the substitutions possible.
* Generate command line argumets using 'command' variable in the 'rule'
and use it as the source of truth, istead of using random known
bindings like 'FLAGS'.
The intention here was to do a component-wise
prefix check, not sure why I did a string prefix
check. Switch to component prefix and rename to
`starts(with:)` to match `FilePath`.
Previously we would avoid adding this since it has
an invalid module name, but we can follow the same
logic as the driver and set the module name to
`main`.
Generate a new 'SwiftRuntimes' xcodeproj if a build directory
for 'Runtimes' is specified with `--runtimes-build-dir`, along with a
combined 'Swift+Runtimes' workspace.
Only consider `.o` and `.swiftmodule` inputs for now. Previously
we could end up with unnecessary dependencies for e.g plugin
dylibs, but we don't build and patch those in currently.
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.
This enables the use of folder references for
compatible targets, allowing new source files to
be added without needing to regenerate the project.
Currently disabled by default; I'd like to get
some living-on before enabling.
This requires ensuring we check that we're not
ever attempting to add a group under an existing
folder reference. This will be required for
buildable folders.
This is a tool specifically designed to generate
Xcode projects for the Swift repo (as well as a
couple of adjacent repos such as LLVM and Clang).
It aims to provide a much more user-friendly experience
than the CMake Xcode generation (`build-script --xcode`).
