Rather than forming a set intersection, only look for a common prefix
with the parent arguments. This is both quicker and more correct
since arguments can be order-dependent. This does mean we'll end up
with more per-file arguments for "umbrella" targets, but that at
least will no longer prevent us from forming buildable folders for
them.
* 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`.
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 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 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`).
