Closed Str1ker17 closed 2 years ago
Hey @Str1ker17 , thanks for the suggestions.
I think the Bear 2.x CLI was using bad naming and wanted to correct it in 3.x. Therefore full backward compatibility won't be a goal for me. Can add short switches (beside the long ones) if that helps.
Yes, short switches would be helpful, because I generate compile_commands by manual invocation of Bear.
If you are busy now for implementing my wishes :), I can send you a PR.
There is a request to merge the delivered executables into a single one. And that requirement clashes with this.
Sorry, but this not going to happen.
Why merging executables makes it impossible to support short options?...
Hello @rizsotto I noticed that this issue is in the todo list for 3.1, but is also closed, so is this feature wanted or not?
Anyway after the single command patch I did, there would be an ambiguity with the short command line arguments:
Consider the command bear intercept
it could be interpreted as "run bear calling the intercept command" or "run bear's intercept subcommand".
I would solve the ambiguity by interpreting it as a subcommand call and if the user really wants to call bear on the intercept command it can be done with the current syntax bear -- intercept
The --
between the Bear parameters and the command will remain. That's an improvement that I would like to keep. We can add short options back if that helps... but I was thinking to do a bit more of these changes:
bear
, intercept
and citnames
we might get rid of the process executions. (as you recommended earlier.)
--bear-path
flag.intercept
and bear
functions to access the configuration file too. (currently only citnames
reads the config file.)
--append
and --run-checks
to be a configuration parameter.These would really shorten the number of characters to type for the calls... The result would be the bear -- make
call.
This case we don't really have anything left which needs to be backward compatible. The remained flags are rarely used and might be okay to leave it long.
Yes, removing the executions is an important edit, but I was getting some failing test and I was procrastinating. Anyway to allow all commands to read the configuration I would move the Configuration.cc file into the bear directory.
After the above edits, in another PR we could do the following ones for ease of use.
Also considering that the config file becomes the only way to configure bear I would make bear automatically check if there is a bear-config.json
file present in the pwd, so there is no need to pass the --config
flag too.
Finally add a bear gen-config
subcommand that creates the template config file that the user can edit.
Hello @rizsotto, thank you for developing and maintaining such an useful tool.
I tried a new Bear 3 on my new Ubuntu 21.10, and found that command-line interface has significantly changed. It is more handy to type
bear -a make
thanbear --append -- make
. Could you make the CLI options compatible to Bear 2?Thanks for attention!