One of the goals of swift-driver is to adopt a library-based architecture for better integration with build tooling. To that end, I've recently been doing some refactoring so that even simple invocations like
swift --version are modeled as driver jobs. This means library clients no longer need to worry about the driver spawning processes they cannot control. Instead, a library client which doesn't want to use the built-in job execution functionality can just obtain a list of jobs and run them on its own if it wants to, for example, do something unusual with stdout.
--help doesn't fit into this model today, because the driver is responsible for printing it directly. This isn't an insurmountable issue, we could just move it's handling out of the
SwiftDriver library and into the
swift-driver binary itself. However, I had an idea after coming across SR-11900, which suggested potentially introducing a
swift-help executable which would fit in with existing subcommand handling and support
In short, I think we should consider adding writing a
swift-help in Swift as part of the
swift-driver project, and use it to entirely replace help handling in the compiler sooner rather than later. The benefits are:
- We'd gain experience integrating a swift package product in compiler toolchains with minimal impact on day-to-day development. Anything we learned could then be applied to
swift-driverlater on. No bootstrapping would be needed since the help text isn't needed to build the compiler.
swift helpbecomes a supported subcommand
- It solves my immediate problem (admittedly not a strong justification)
- We could delete a little bit of C++ from the frontend
The main downside I see is that it seems a little silly to
exec another process just to print help info.
I'd be interested in hearing other's opinions!