-
Notifications
You must be signed in to change notification settings - Fork 403
New issue
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
Iox #404 Fix verbose output and introduce CmdLineArgs_t struct #523
Iox #404 Fix verbose output and introduce CmdLineArgs_t struct #523
Conversation
…neParser Signed-off-by: Simon Hoinkis <[email protected]>
Signed-off-by: Simon Hoinkis <[email protected]>
Signed-off-by: Simon Hoinkis <[email protected]>
Signed-off-by: Simon Hoinkis <[email protected]>
Signed-off-by: Simon Hoinkis <[email protected]>
Signed-off-by: Simon Hoinkis <[email protected]>
…#404-fix-verbose-output
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have tests for the CmdLineParser
?
cmdLineParser.printParameters(); | ||
|
||
IceOryxRouDiApp roudi(cmdLineParser, roudiConfig); | ||
IceOryxRouDiApp roudi(cmdLineArgs, roudiConfig); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to only have the roudiConfig
here. Ideally such things like the LogLevel could also set by TOML but the cmd line would have a higher precedence. Maybe something for another PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, good point. For me this is related to the RouDi refactorings for safety certificiation. This epic should be started with #230
Signed-off-by: Simon Hoinkis <[email protected]>
e316481
to
c582303
Compare
Signed-off-by: Simon Hoinkis <[email protected]>
…st cases Signed-off-by: Simon Hoinkis <[email protected]>
{"kill-delay", required_argument, nullptr, 'k'}, | ||
{nullptr, 0, nullptr, 0}}; | ||
|
||
// colon after shortOption means it requires an argument, two colons mean optional argument | ||
constexpr const char* shortOptions = "hvm:l:u:c:k:"; | ||
constexpr const char* shortOptions = "hvm:l:u:x:k:"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hope this change won't lead to misfortune 😆
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh no, the luck is gone 😆
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, there was a clash with the --config-file
option. It's a bit unfortunate that the long option doesn't start with the same letter as the short option. Maybe we can think of something that also fits and doesn't yet have a short option.
Signed-off-by: Simon Hoinkis <[email protected]>
iceoryx_posh/include/iceoryx_posh/roudi/roudi_cmd_line_parser.hpp
Outdated
Show resolved
Hide resolved
{"kill-delay", required_argument, nullptr, 'k'}, | ||
{nullptr, 0, nullptr, 0}}; | ||
|
||
// colon after shortOption means it requires an argument, two colons mean optional argument | ||
constexpr const char* shortOptions = "hvm:l:u:c:k:"; | ||
constexpr const char* shortOptions = "hvm:l:u:x:k:"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, there was a clash with the --config-file
option. It's a bit unfortunate that the long option doesn't start with the same letter as the short option. Maybe we can think of something that also fits and doesn't yet have a short option.
Signed-off-by: Simon Hoinkis <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only one minor point to consider otherwise looks good.
Signed-off-by: Simon Hoinkis <[email protected]>
@@ -25,7 +25,12 @@ int main(int argc, char* argv[]) | |||
static constexpr uint32_t ONE_MEGABYTE = 1024U * 1024; | |||
|
|||
iox::config::CmdLineParserConfigFileOption cmdLineParser; | |||
cmdLineParser.parse(argc, argv); | |||
auto cmdLineArgs = cmdLineParser.parse(argc, argv); | |||
if (cmdLineArgs.has_error() && (cmdLineArgs.get_error() != iox::config::CmdLineParserResult::INFO_OUTPUT_ONLY)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is INFO_OUTPUT_ONLY
an error or success result ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neither an error nor a success, but something inbetween. This is why I called it CmdLineParserResult
and not CmdLineParserError
. We did the same for removing the optional
inside a expected
for the new v1.0 API. However, the methods are still called get_error()
. We might consider renaming them to get_result()
but that is somehow ambiguous.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah... but then get_error
can be a lie !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rust uses the same terminology for Result
as we currently do for the expected
.
@elBoberido What's your take on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
both of you are right ... and I have to leave 😁
get_unexpected
might be a better name is this case, but I'm not quite sure what's in the expected
proposal.
As mossmaurice pointed out, Rust does it the same way, although it would be more idiomatic to use a Result<Option<CmdLineArgs>, E>
in this case.
I'm slightly leaning towards being pragmatic and keep it as it is, since we are doing the same with takeResult
in the Subscriber
. We could think of renaming the method, though.
Pre-Review Checklist for the PR Author
iox-#123-this-is-a-branch
)iox-#123 commit text
)git commit -s
)Notes for Reviewer
./iox-roudi --help
RouDiApp
instead of in mainCmdLineParser&
toCmdLineArgs_t
struct to make RouDi more modularCmdLineParser*
unit testsChecklist for the PR Reviewer
Post-review Checklist for the PR Author
Post-review Checklist for the Eclipse Committer
References