Closed timotheecour closed 5 years ago
At some point I was considering --
syntactically (parseopt3
, probably) for multiple non-defaulted seq[string]
type non-option parameters. This is sort of similar to that, except you want option groups. It's definitely not supported right now. To be honest, I'm not really against the feature, but it seems pretty tricky to get right. I don't know if you've looked at the initGen
/initFromCL
impl, but I think it's kind of a layering violation given the current layering.
It's not as "nice" a CL syntax, but with what is currently supported you could just have a seq[string]
inside your type Foo
and have the user do a bunch of --opts,+=-subopt1-arg1 --opts,+=-subopt2-arg2
. There is precedent for this sort of syntax for "pass through". E.g., gcc
's -Wl,loader-options1 -Wl,loader-options2
. nimble install
also recently grew a similar -p:-d:release
nesting.
I realize that generating or entering a bunch of --opts,+=
-style params is not great, and it's not a stellar UI. Depending on expectations of needs for quoted arguments, another idea would be to take a giant string, perhaps expected to be single quoted, and do an os.parseCmdLine
inside main
to turn that into a seq[string]
.
I'm just sort of trying to think about/help with your problem with what seems easy to do right now. At first blush, it seems hard-to-maybe-impossible to achieve exactly what you want without breaking other features, but if you want to work on it I am not opposed to a PR or something.
Well, I am closing this for now unless a clean implementation strategy can be identified. Happy to re-open if you have any ideas.
I want to combine both initFromCL (to group params into an object) and gather extra command line params. Is that supported?
If not how about:
this is useful eg to forward command line invocations (eg for calling nim with cmd line params)