@xkaraman I hope you will agree to add this jobs related to cmake files to keep things tidy. You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4066
-- Commit Summary --
* pre-commit: cmake-format and cmake-lint hooks [skip ci]
-- File Changes --
M .pre-commit-config.yaml (7)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4066.patch https://github.com/kamailio/kamailio/pull/4066.diff
It is fine for me.
Yes, definitely agree!!
Merged #4066 into master.
@linuxmaniac Is this pre-commit using the `cmake-format.py` config file found in `cmake` or it just go by the defaults?
If we are fine with the defaults, we can remove the file completely, as it might mess up the format if configured to use the one provided (happened to me that I was already using the one in `cmake` :) ).
If a custom config is going to be used, maybe it would be good to tune it a bit, since we are at the beginning of using cmake files. For example I would suggest a longer `line_width`, 80 was (maybe still is) for code to be easily seen on the very old terminal/console, but considering the current displays as well as terminal apps, it could be more convenient to have it like 120 or so. Otherwise we may end up in splitting lines/strings that are maybe not very long, but they are impacted by indentation.
@miconda Sure thing, all the available options, are in that `cmake/cmake-format.py`.
We can also use other formats apart from python conf file, like yaml or json. `cmake-format --dump-config [yaml|json|python] > file.ext` will output all the default configs so that we can manually edit it afterwards at out style.
So, for now, I will also use the defaults, to have no differences when committing code, until we decide to change them.
Not to continue the discussion on this closed PR, I created tracker issue for it: #4075.
@linuxmaniac @miconda: Question regarding these checks!
Are they enforced when pushing directly to master, if someone has not setup locally the pre-commit python module and not being warned?
Ideally, when pushing to master, it must not accept code (either cmake or c), that does not conform to the format requested.
On pull request we have the checks, so we can know about it. On the direct commit, if the author does not have locally the `pre-commit`, it seems to me that it can push with whatever format.