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.
We can define exceptions to handle targets with sources that either
have unique arguments or are unbuildable. Eventually this ought to
allow us to ditch the "no outside-target source file" rule, but I'm
leaving that be for now since ideally we'd handle automatically
splitting up umbrella Clang targets such as `stdlib` such that e.g
`swiftCore` is its own buildable folder instead of an exception.
This was originally a separate library since it was copied directly
from the legacy SwiftPM library. However it's since been changed a
bunch, and ought to be able leverage SwiftXcodeGen utilities such as
RelativePath. Fold it into SwiftXcodeGen.
I considered splitting out the utility code from SwiftXcodeGen into
a new library, but unfortunately that currently regresses performance
(even with max CMO). The module organization doesn't really currently
matter since we don't expose any products.
* 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`).
