Backwards-compatible command line options

rizsotto / Bear

Bear is a tool that generates a compilation database for clang tooling.

GNU General Public License v3.0

4.76k stars 312 forks source link

Backwards-compatible command line options #429

Closed Str1ker17 closed 2 years ago

Str1ker17 commented 2 years ago

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 than bear --append -- make. Could you make the CLI options compatible to Bear 2?

Thanks for attention!

rizsotto commented 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.

Str1ker17 commented 2 years ago

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.

rizsotto commented 2 years ago

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.

Str1ker17 commented 2 years ago

Why merging executables makes it impossible to support short options?...

samu698 commented 1 year ago

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

rizsotto commented 1 year ago

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:

since there is one executable for bear, intercept and citnames we might get rid of the process executions. (as you recommended earlier.)
- this can remove the --bear-path flag.
that will allow intercept and bear functions to access the configuration file too. (currently only citnames reads the config file.)
- this enables the --append and --run-checks to be a configuration parameter.
- can make the append as a default behavior
- can make the check as default behavior too

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.

samu698 commented 1 year ago

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.