https://github.com/apache/incubator-nuttx/pull/47 checkpatch.sh is ready, you can invoke it like this: tools/checkpatch.sh -p patch-list tools/checkpatch.sh -c commit-list tools/checkpatch.sh -f file-list The first two just check the modified portion, the last one check the whole content. And with the below commands: echo "git diff --cached | ./tools/checkpatch.sh -" > .git/hooks/pre-commit chmod a+x .git/hooks/pre-commit git will do the check each new commit automatically. Haitao will incorporate it into the github in the next couple day.
On Tue, Jan 7, 2020 at 8:18 PM Alin Jerpelea <jerpe...@gmail.com> wrote: > > I think that we should update all code with nxstyle then we start with a > clean code on which patches will be checked > Should we distribute the job to committer or interesting people? > Alin > > On Tue, Dec 31, 2019 at 3:42 PM Haitao Liu <liugu...@gmail.com> wrote: > > > Greg, I'll finish the nxstyle & check script these days firstly and then > > take time to handle the two issues you mentioned if allowed. I wish I could > > be competent to take over full responsibility for nxstyle.c. > > > > Gregory Nutt <spudan...@gmail.com> 于2019年12月30日周一 下午11:31写道： > > > > > [moved from priv...@nuttx.apache.org] > > > > > > Hi, Xiao Xiang and Haitao Liu > > > > > > > Haitao is preparing a script for style check, the feature include: > > > > 1.Auto build nxstyle > > > > 2.Improve nxstyle to check the partial file for supporting patch like > > > file > > > > 3.Input can be the source files, patch file or commit id > > > > > > I mentioned that I had two things I planned to do for nxstyle.c too. > > > Perhaps Haitao would like to take on these changes too? > > > > > > 1. Derive maximum line width from block comments. Ref: > > > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#fileorganization > > > > > > * The Maximum line width should be the same as the width of the file > > > section block comment, by default the last asterisk '*' lies on > > > column 78, but wider lines are okay too, as long as things are > > > scaled corrected. Instead of the line width being a hardcoded 78 or > > > specified the command line, nxstyle would parse the entire file, > > > look at the block comments, find the column of the last '*' The > > > line width is that colument + 1; > > > * Then also verify that every block comment in the file is the same > > width > > > * Perhaps the -m argument could change to a amount that you will > > > tolerate extending into the right margin. So the block comment with > > > is 78, then -m 8 would allow lines to extend to 86. That is better > > > than a hard-coded 86 because the line width will vary with file > > > content. For some register definition files, the line width may be > > > 120 or so. In that case -m 8 would allow the line to extend to 128. > > > > > > 2. Verify that file section block comments are present. > > > > > > * Add an enumeration value that indicates every block comment type. > > > See > > > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#cfilestructure > > > and > > > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#hfilestructure > > > * Currently logic detects only the presence of "* Private Functions" > > > and "* Private Functions". Add logic to detect all other the block > > > comment types as well. > > > * Add a global variable to indicate which code block we are currently > > > in. Each time a file section block comment is found, set the global > > > variable. > > > * The if '# define" is encountered outside of the "* Pre-processor > > > Definitions" file section, emit an error > > > * If '# include" is encountered outside of the "* Included Files" > > > section, emit an error. > > > * This logic could eventually be extended to assure that all static > > > functions are defined in the "* Private Functions" section, all > > > global functions are defined in the "* Public Functions section", > > > all static data definitions appear in the "* Private Data" section, > > > and all global data definitions appear in the "* Public data > > > definitions." > > > * We could also enable special parsing depending on the section. That > > > is already done for the Public/Private Functions. But we could, for > > > example also verify that variables defined at global scope start > > > with "g-" > > > > > > Let me know. I was planning to do these things, but if Haitao Liu is > > > interested, he can take over full responsibility for nxstyle.c. > > > > > > Greg > > > > > > > > > > > > > > > > >
