This is the mail archive of the
mailing list for the GCC project.
Re: Transformation of contrib/check_GNU_style.sh to a python script
- From: Martin Sebor <msebor at gmail dot com>
- To: Martin Liška <mliska at suse dot cz>, GCC Development <gcc at gcc dot gnu dot org>
- Cc: Tom_deVries at mentor dot com
- Date: Mon, 15 May 2017 14:35:05 -0600
- Subject: Re: Transformation of contrib/check_GNU_style.sh to a python script
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org>
On 05/15/2017 07:55 AM, Martin Liška wrote:
Recently I've been working on bigger changes to dump infrastructure and I had to
fix tens of formatting issues reported by check_GNU_style.sh script. The script works
quite fine, but it's very unpleasant that it reports problematic lines in the patch,
not in original patches.
I was a little confused by this but in the end decided that you
must have meant "not in the original sources." I can see how
having the script generate a patch to fix the problems it finds
could be handy.
I decided to substitute part of functionality by Python
script that uses a library that parses patches. So that reported errors can be
easily converted to quickfix list for VIM. That makes navigation very easy.
I'm attaching simple version that I made in couple of minutes and I would like to
ask whether the bash script is broadly used and whether community would be interested
in transformation of the script?
I use the script less and less as I become more comfortable with
the GCC style, and I don't expect to be making significant changes
to it. I'm sure it can be improved and/or simplified but I have
developed a (shell/awk/sed) script of my own that automatically
fixes most of these little things for me while applying a patch,
so I don't have to worry about them while writing code.
That said, I don't really see a very compelling reason to rewrite
this script in Python or other high-level language, or add another
dependency for contributors to have to remember to install to use
it. I'd rather see the effort invested into a smart commit hook
that would format all code for us the expected way automatically.
(That would save enough hassle to justify introducing a dependency
on almost any language or library ;-)