Re: [Dnsmasq-discuss] clang format
On Sat, Oct 12, 2019 at 11:56:58PM +0100, Simon Kelley wrote: > On 10/10/2019 22:00, Geert Stappers wrote: > > Previous-Subject: Re: [Dnsmasq-discuss] [patch] empty empty lines > > In-Reply-To: <55adb604-91a9-77a8-ed41-500363f4c...@mail.com> > > On Mon, Sep 30, 2019 at 07:18:12PM +0200, john doe wrote: > >> On 9/30/2019 4:50 PM, Simon Kelley wrote: > >>> > >>> ... > >>> > >>> So, let's come to a consensus if a one-time clean up commit across the > >>> codebase is a price worth paying to fix the formatting issues, and if it > >>> is, work out how to add automatic filters to git to keep things clean > >>> afterwards. If anyone has experience of that, I'd like to hear. > >>> > >> > >> The way I see things which is up for debate: > >> - Everyone that is committing to the project would need to use > > > > Where it is OK to get tooling to bend our source code in shape, > > is it more important to decide in which shape it should be bend. > > > > ... Linux kernel (C language, several contributors) > > have code style documented and have machine reable version ... > > > > Tooling they use is `clangformat` > > https://clang.llvm.org/docs/ClangFormat.html > > > > > > Please take the above information as input for moving Dnsmasq from > > a project without a coding style to a project with a coding style. > > > > > This seems to have escalated from inconsistent use of spaces and tabs to > "without a coding style". For information, the C coding style in dnsmasq > is the GNU style, except without the space preceding ( > > I like that style, I chose that style and it's not going to change. > Having that choice machine readable in the Dnsmasq source tree is what I'm aiming for. Manual page of clang-format (version 8.0.1) says -style= - Coding style, currently supports: LLVM, Google, Chromium, Mozilla, WebKit. I don't know which one is closest to the GNU style. A websearch on "clang format gnu style" did yield a mailinglist posting https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02214.html It starts with Following patch adds a clang-format config file that should respect the GNU coding standards. Recent version is https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=contrib/clang-format Groeten Geert Stappers -- Leven en laten leven ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] clang format
On 10/10/2019 22:00, Geert Stappers wrote: > > In-Reply-To: <55adb604-91a9-77a8-ed41-500363f4c...@mail.com> > Previous-Subject: Re: [Dnsmasq-discuss] [patch] empty empty lines > On Mon, Sep 30, 2019 at 07:18:12PM +0200, john doe wrote: >> On 9/30/2019 4:50 PM, Simon Kelley wrote: >>> To be clear, I have no objection to this sort of patch/suggestion. >>> >>> It should be fairly clear, however, that my available time to work on >>> dnsmasq at the moment is limited, and stuff like this is not a priority, >>> and likely to be pushed to the back of the queue, possibly so far that >>> it never emerges again. >>> >>> If we're going to do this, the first stage is probably to add hooks to >>> git to run expand (for tabs) and this filter on all NEW commits. Then >>> we won't ever have to do that again. >>> >>> As that filter will make massive updates to existing code, we'll have >>> to take a one-time commit across the codebase to get everything fixed >>> once. Otherwise the filters will adding lots of extra formatting changes >>> to other commits as they touch files, which is not good. >>> >>> So, let's come to a consensus if a one-time clean up commit across the >>> codebase is a price worth paying to fix the formatting issues, and if it >>> is, work out how to add automatic filters to git to keep things clean >>> afterwards. If anyone has experience of that, I'd like to hear. >>> >> >> The way I see things which is up for debate: >> - Everyone that is committing to the project would need to use a Git >> hook that would avoid committing if the code is not conform to the >> standard used by the project >> The pre-commit hook '.git/hooks/pre-commit' would need to be >> modified to fit the coding stile required by the project which means >> that patch that does not comply to the coding stile will be rejected. >> >> The above is only for new code that would be added, now to the question >> of modifying code already pushed: >> If we choose to reformat old pushed code, one commit should be created >> including all the formatting issues then testing will need to be done to >> verify that the commit in question does not introduce regression, >> reformatting old code is questionable to say the lease. > > > Where it is OK to get tooling to bend our source code in shape, > is it more important to decide in which shape it should be bend. > > Here I think it is wise to be standing on the shoulders of giants. > The giants are this time the Linux Kernel developers. > > Those giants have their coding style described. > https://www.kernel.org/doc/html/v5.3/process/coding-style.html > > Machine readable version is > at > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/.clang-format > > Tooling they use is `clangformat` > https://clang.llvm.org/docs/ClangFormat.html > > > Please take the above information as input for moving Dnsmasq from > a project without a coding style to a project with a coding style. > This seems to have escalated from inconsistent use of spaces and tabs to "without a coding style". For information, the C coding style in dnsmasq is the GNU style, except without the space preceding ( I like that style, I chose that style and it's not going to change. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] clang format
In-Reply-To: <55adb604-91a9-77a8-ed41-500363f4c...@mail.com> Previous-Subject: Re: [Dnsmasq-discuss] [patch] empty empty lines On Mon, Sep 30, 2019 at 07:18:12PM +0200, john doe wrote: > On 9/30/2019 4:50 PM, Simon Kelley wrote: > > To be clear, I have no objection to this sort of patch/suggestion. > > > > It should be fairly clear, however, that my available time to work on > > dnsmasq at the moment is limited, and stuff like this is not a priority, > > and likely to be pushed to the back of the queue, possibly so far that > > it never emerges again. > > > > If we're going to do this, the first stage is probably to add hooks to > > git to run expand (for tabs) and this filter on all NEW commits. Then > > we won't ever have to do that again. > > > > As that filter will make massive updates to existing code, we'll have > > to take a one-time commit across the codebase to get everything fixed > > once. Otherwise the filters will adding lots of extra formatting changes > > to other commits as they touch files, which is not good. > > > > So, let's come to a consensus if a one-time clean up commit across the > > codebase is a price worth paying to fix the formatting issues, and if it > > is, work out how to add automatic filters to git to keep things clean > > afterwards. If anyone has experience of that, I'd like to hear. > > > > The way I see things which is up for debate: > - Everyone that is committing to the project would need to use a Git > hook that would avoid committing if the code is not conform to the > standard used by the project > The pre-commit hook '.git/hooks/pre-commit' would need to be > modified to fit the coding stile required by the project which means > that patch that does not comply to the coding stile will be rejected. > > The above is only for new code that would be added, now to the question > of modifying code already pushed: > If we choose to reformat old pushed code, one commit should be created > including all the formatting issues then testing will need to be done to > verify that the commit in question does not introduce regression, > reformatting old code is questionable to say the lease. Where it is OK to get tooling to bend our source code in shape, is it more important to decide in which shape it should be bend. Here I think it is wise to be standing on the shoulders of giants. The giants are this time the Linux Kernel developers. Those giants have their coding style described. https://www.kernel.org/doc/html/v5.3/process/coding-style.html Machine readable version is at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/.clang-format Tooling they use is `clangformat` https://clang.llvm.org/docs/ClangFormat.html Please take the above information as input for moving Dnsmasq from a project without a coding style to a project with a coding style. Groeten Geert Stappers -- Leven en laten leven ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
