We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
If I haven't overlooked something, it's currently not possible to define options in the style of make/gcc/clang definitions.
In theory it should be possible to define it like this:
@main struct Foo: ParsableCommand { @Option(name: .customShort("D", allowingJoined: true), parsing: .singleValue) var defines: [String] = [] public func run() throws { print(defines) } }
This works fine for calling the executable e.g. like so:
$ foo -Dbar -Dbaz ["bar", "baz"]
However, when the value of the option contains an =, this doesn't work anymore:
$ foo -Dbar=baz Error: Unknown option '-Dbar'
I'd guess that after seeing an equals sign the single "D" isn't considered anymore. It would be great, if that behaviour could be changed.
Of course, it would be possible to go an extra step and fully parse such key-value pairs into a dictionary. I could imagine a syntax like this:
@main struct Foo: ParsableCommand { @Option(name: [.customShort("D", allowingJoined: true), .customLong("define")]) var defines: [String: String] = [:] public func run() throws { print(defines) } }
Where Option gets a new specialized init for Value == [String: Element] that then would work like that:
Option
Value == [String: Element]
$ foo -Dbar=1 -D baz=2 --define qux=3 ["bar": 1, "baz": 2, "qux": 3]
The text was updated successfully, but these errors were encountered:
No branches or pull requests
If I haven't overlooked something, it's currently not possible to define options in the style of make/gcc/clang definitions.
In theory it should be possible to define it like this:
This works fine for calling the executable e.g. like so:
However, when the value of the option contains an =, this doesn't work anymore:
I'd guess that after seeing an equals sign the single "D" isn't considered anymore. It would be great, if that behaviour could be changed.
Of course, it would be possible to go an extra step and fully parse such key-value pairs into a dictionary. I could imagine a syntax like this:
Where
Option
gets a new specialized init forValue == [String: Element]
that then would work like that:The text was updated successfully, but these errors were encountered: