Re: tools brainstorming

["Wiles, Keith" <keith.wiles-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

On 4/14/15, 10:24 AM, "Thomas Monjalon" <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org> wrote:

>2015-04-14 15:52, Bruce Richardson:
>> On Wed, Apr 08, 2015 at 06:16:12PM +0200, Thomas Monjalon wrote:
>> > When a consensus is done, it must be added with a patch with custom
>> > checkpatch addition.
>> > 
>> My personal feeling is that we should try and keep checkpatch
>>modifications to a
>> minimum. Right now, we can use checkpatch as-is from kernel.org, right?
>
>Yes that's something we have to discuss.
>It should be preferred to avoid "forking" checkpatch.
>
>At the moment, I'm using this configuration:
>
>	options="$options --max-line-length=100"
>	options="$options --show-types"
>	options="$options --ignore=LINUX_VERSION_CODE,FILE_PATH_CHANGES,\
>	VOLATILE,PREFER_PACKED,PREFER_ALIGNED,PREFER_PRINTF,\
>	SPLIT_STRING,LINE_SPACING,NEW_TYPEDEFS,COMPLEX_MACRO"
>
>	linux/scripts/checkpatch.pl $options
>
>I would like to submit a script to run checkpatch with DPDK configuration
>when the coding rules are clear.
>
>However, I've already seen some options which are not enough configurable
>(don't remember which one). For such corner case, I would see 3 solutions
>(from the most to the least desired):
>	- submit a patch to allow more configuration to kernel.org
>	- give up automatic handling of corner cases
>	- maintain a fork in scripts/ directory
Here is the next solution
	- Stop using checkpatch and use a real tool for formatting code instead.
If someone uses a tool before commit, then create the patch which does not
require checkpatch.
Most of these tools can define an output file or they leave behind the
original file as a backup or we can see if they have a non-modify mode and
just points out the problems. As in astyle '--dry-run' can be used, plus
it saves the original file as XXXXX.orig or you can change the .orig to
your own value.
>