Greg, Xiang and All, Since code check part is available now, could I and Duo prepare to setup Jenkins CI job firstly? At fist, start to do the PR check stage according to the workflow option chosen, then go to the build stage in the next couple of days. We could optimize all the stages step by step once we start working on it : )
Xiang Xiao <xiaoxiang781...@gmail.com> 于2020年1月8日周三 上午10:30写道： > David, why you think this tool promote the violation? > With -p or -c option, we can ensure no new code violate the coding style. > With -f option, we can review and correct the current code base. > The jenkins job can select one option base on the workflow definition, > the tool self hasn't any preference. > Base on your measurement: > https://github.com/apache/incubator-nuttx/pull/12 > 4043 files doesn't confirm the coding standard, how about each > committer(candidate) take several folders to fix the style issue? > > On Wed, Jan 8, 2020 at 12:40 AM David Sidrane <david.sidr...@nscdg.com> > wrote: > > > > +1 > > > > Adding a tool that promotes violating the INVIOLABLES.txt on several > aspect > > (expedience and non conformant code into the repo) feels like a very bad > > choice. > > > > How is this being justified? > > > > David > > > > > > -----Original Message----- > > From: Alin Jerpelea [mailto:jerpe...@gmail.com] > > Sent: Tuesday, January 07, 2020 4:18 AM > > To: dev@nuttx.apache.org > > Subject: Re: Working Effectively (was Point of Order) > > > > I think that we should update all code with nxstyle then we start with a > > clean code on which patches will be checked > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > >
