BUILD(shared): build CLI11 into shared target

[WOLFI3654]

Implements #6063

Checks

• My commits follow the commit guidelines

[WOLFI3654]

Just started working on this. There are two questions I already have:

1. How are translations handled for the flags itself and the flag descriptions?
2. Should be flags be rewritten to follow general cli standards? from my understanding "-third-party-licenses" would be a bit odd since the single dash is mostly only used for shorthands ( in this case something like -tpl)

[WOLFI3654]

2. Should be flags be rewritten to follow general cli standards?

Probably interesting for this as well: CLI11 does not permit single args that have more than one character

[WOLFI3654]

Also I am having difficulties getting --help to work under windows. It looks like this never really worked in the first place.

[Hartmnt]

1. How are translations handled for the flags itself and the flag descriptions?

It looks like neither flags nor descriptions are currently translated. I would say translating the flags itself is not something we want. Translating the descriptions would make sense, but it would require to wrap all descriptions into QObject::tr() call. The actual translations are then community created outside of this MR - once it is merged.

2. Should be flags be rewritten to follow general cli standards? from my understanding "-third-party-licenses" would be a bit odd since the single dash is mostly only used for shorthands ( in this case something like -tpl)

I would say yes, except when you encounter something that could potentially break servers or their automation. In that case we should look at that again in particular.

But, let's also have input from @Krzmbrzl for that

[WOLFI3654]

I would say yes, except when you encounter something that could potentially break servers or their automation. In that case we should look at that again in particular.

I'd say most of these are breaking since single dash is forbidden for multicharacter options. And on server side, most of the options are.

[Krzmbrzl]

How are translations handled for the flags itself and the flag descriptions?

Flags should definitely not be translated. Their description don't need to be translated either imo - though this is open for discussion. Maybe omitting translation for now and then looking into that once requested would be an OK approach?

Should be flags be rewritten to follow general cli standards? from my understanding "-third-party-licenses" would be a bit odd since the single dash is mostly only used for shorthands ( in this case something like -tpl)

Yes - I think CLI11 doesn't even support non standard flags 👀

Also I am having difficulties getting --help to work under windows. It looks like this never really worked in the first place.

That might very well be the case - on Windows Mumble essentially never gets started from a command line.

It looks like neither flags nor descriptions are currently translated.

The description is currently translated - which is a massive PITA if you ask me as the help text is translated in its entirety.

[WOLFI3654]

Yes - I think CLI11 doesn't even support non standard flags 👀

Thank you, yeah, this confirms what I figured. So this whole MR will basically be a breaking change for anyone using the CLI in automation. Unless we add some kind of mapping layer that will sort of “up cast” the old parameters to the new system. Is that something we should go for to smooth out the transition or do we just roll with the break, since the jump from 1.4 to 1.5 would be a somewhat good opportunity to refactor / re-think the CLI.

[Krzmbrzl]

I would roll with the break as I don't think maintaining support for non-standard flags makes sense for the future, so eventually we'll have to make a break (or keep the mess of manual option handling that we currently have) 🤔

since the jump from 1.4 to 1.5 would be a somewhat good opportunity to refactor / re-think the CLI.

This PR won't be part of 1.5 anymore, but 1.6 will do equally fine :)

[Krzmbrzl]

I think we should stick to tagged releases of CLI11 - the latest of these would be https://github.com/CLIUtils/CLI11/releases/tag/v2.3.2 as of this writing.

[WOLFI3654]

Submodule should be put at head of tag now

[Krzmbrzl]

Please add the dependency to the client and the server explicitly - the shared target really should only have dependencies for the shared code and not dependencies that both components happen to create in their own code respectively.

[Krzmbrzl]

If possible, I would like to stick to std-types. If that would make things a lot more complicated, stick to using Boost though.

[WOLFI3654]

I tried using std types and experienced some issues since they are not always available depending on which target system is built. Yeah boost is quite expensive to compile, I agree - not using them would be better. I'll try to see if I can remove them after things work

[Krzmbrzl]

std-types should always present. You only have to check to stick to std types included in up to cpp14 as that's the current standard we are using.

[WOLFI3654]

Sadly, std::optional is not avalable in cpp14 afaik. I'll try to find another solution.

[Krzmbrzl]

Yes, but an empty string will do equally fine for indicating that the INI file has not been specified :)