Right now, to use our test_tool_info and check_cgroups functionality, users have to use commands like python3 -m benchexec.test_tool_info .... This is documented, but not easy to remember. We could make this easier by providing a direct entry point.
One way would be to drop more executables in the user's PATH, like test-benchexec-tool-info or so. But this is also hard to discover and clutters the global namespace.
A common way to have one executable with several distinct personalities / modes is to use tool verb args. We could use this and have something like benchexec test-tool-info ....
It is somewhat uncommon to have a tool with some modes that use such verbs and one mode that does not use a verb (the standard benchmarking mode), but we can live with that.
For check_cgroups, both benchexec and runexec could gain that verb.
Right now, to use our test_tool_info and check_cgroups functionality, users have to use commands like
python3 -m benchexec.test_tool_info ...
. This is documented, but not easy to remember. We could make this easier by providing a direct entry point.One way would be to drop more executables in the user's
PATH
, liketest-benchexec-tool-info
or so. But this is also hard to discover and clutters the global namespace.A common way to have one executable with several distinct personalities / modes is to use
tool verb args
. We could use this and have something likebenchexec test-tool-info ...
. It is somewhat uncommon to have a tool with some modes that use such verbs and one mode that does not use a verb (the standard benchmarking mode), but we can live with that.For
check_cgroups
, bothbenchexec
andrunexec
could gain that verb.