Re: [libmicrohttpd] clang formatting discussion via [gnunet-developers]
n...@n0.is transcribed 9.3K bytes:
> Christian Grothoff transcribed 11K bytes:
> > Dear MHD hackers,
> >
> > There has been a (long-ish) discussion about using clang-format for
> > source formatting among the GNUnet developers. WDYT about applying the
> > same/similar rules to GNU libmicrohttpd and also enforcing them via Git
> > hooks on commit? I've attached the .clang-format file that resulted from
> > the GNUnet discussion here.
>
> Did you reach any consensus on this discussion here?
> I'm already clang-formatting my code for lmhd but no
> .clang-format exists in the repository.
I've noticed another issue in clang-format from llvm-project.git
54763e44532feb72bf773260b377f2a0bacf0e0c and base llvm+clang+... version 7.0:
If you have a couple of preprocessor #if directives, and you conditionally
close if conditions not in the same #if block, clang-format assumes the
if conditions are never closed.
example:
#if HAVE_FOO
if (something) {
foo;
if (otherthing) {
foo;
#endif
#if HAVE_BAR
if (newthing) {
bar;
if (newthing) {
bar;
#endif
} else {
errx(1, "Error: %s", bla);
}
}
This could be an error with clang-format, or my mixture
of versions (which otherwise works alright).
> If you require an entirely different style,
> contributing to LibFormat and clang-format is an option.
> I plant to do this with the outstanding KNF for NetBSD.
>
> As far as I know we weren't 100% okay with the results
> for gnunet but already use it.
>
> > See in particular the following e-mails from the GNUnet discussion:
> >
> >
> > On 4/15/19 10:02 AM, Schanzenbach, Martin wrote on [GNUnet-developers]:> Hi,
> > >
> > > FYI I added a clang-format at "contrib/conf/editors/clang-format".
> > > Clang-format is usable with most editors (vim, emacs, vscode) with
> > respective plugins.
> > > This way, we can have a unified coding style.
> > > Clang-format has a nice documentation and allows fine-grained setting
> > which are also human readable:
> > https://clang.llvm.org/docs/ClangFormatStyleOptions.html
> > >
> > > Let's use it and put it as a note into our coding guidelines?>
> >
> > Martin also wrote:
> >
> > > Most editors have plugins:
> > >
> > > emacs:
> > https://llvm.org/svn/llvm-project/cfe/trunk/tools/clang-format/clang-format.el
> > > (n)vim: https://github.com/rhysd/vim-clang-format
> > > vscode: native
> > > sublime: https://packagecontrol.io/packages/Clang%20Format
> >
> > And most recently I wrote (latest point of the discussion):
> >
> > >
> > > Yes, the question is this: are there any developers here where their
> > > editor cannot be reasonably integrated with clang-format? If so, please
> > > do shout out now!
> > >
> > > I've so far heard only positive feedback for Martin's overall initiative
> > > to get indentation under control, so for now I'll proceed with the
> > > assumption that there are no blockers. But if you do have an issue with
> > > this, please do let me know (on or off list) as soon as possible. If
> > > there are no (sound) objections soon, I will give ng0/schanzen the
> > > go-ahead to enable enforcement of clang formatting for all Git commits
> > > in the future!
> > >
> > > Anyway, aside from the general policy debate, please read on for more
> > > specific related issues.
> > >
> > > Deployment experience
> > >
> > > I had to install clang-format-9 from Debian experimental, as our
> > > configuration includes options that are only in v9.
> > >
> > > For Emacs user's reference: Without v9, the Emacs integration silently
> > > failed. I also had to create a symlink from clang-format to
> > > clang-format-9, as the Emacs integration only looks for the clang-format
> > > binary (and otherwise also fails silently).
> > >
> > >
> > > Other than that, Emacs integration was straightforward:
> > >
> > > I added to gnunet/.dir-locals.el a hook on save (this may end up in Git
> > > "soon")
> > >
> >
> > > ((c-mode
> > > (eval add-hook 'before-save-hook #'clang-format-buffer nil t)))
> > > <<<
> > >
> > >
> > > and to .emacs the logic to find the clang-format package
> > >
> >
> > > (require 'package)
> > > (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/";))
> > > ;; initialize package system
> > > (package-initialize)
> > > ;; actually load the package
> > > (require 'clang-format)
> > > <<<
> > >
> > > And of course also installed the clang-format package (interactively,
> > > M-x install-package) as per documentation from Martin's first link above.
> > >
> > > Finally, the clang-format style symlink must be set:
> > >
> > > # Install clang format symlink
> > > ln -s contrib/conf/editors/clang-format .clang-format
> > >
> > > (this I will at to the bootstrap script).
> > >
> > >
> > > Formatting gripes
> > >
> > > My remaining main issue with
> > > https://clang.llvm.org/docs/ClangFormatStyleOptions.html
> > > is that it cannot currently be forced to put a break after ea
Re: [libmicrohttpd] clang formatting discussion via [gnunet-developers]
n...@n0.is transcribed 10K bytes:
> n...@n0.is transcribed 9.3K bytes:
> > Christian Grothoff transcribed 11K bytes:
> > > Dear MHD hackers,
> > >
> > > There has been a (long-ish) discussion about using clang-format for
> > > source formatting among the GNUnet developers. WDYT about applying the
> > > same/similar rules to GNU libmicrohttpd and also enforcing them via Git
> > > hooks on commit? I've attached the .clang-format file that resulted from
> > > the GNUnet discussion here.
> >
> > Did you reach any consensus on this discussion here?
> > I'm already clang-formatting my code for lmhd but no
> > .clang-format exists in the repository.
>
> I've noticed another issue in clang-format from llvm-project.git
> 54763e44532feb72bf773260b377f2a0bacf0e0c and base llvm+clang+... version 7.0:
>
> If you have a couple of preprocessor #if directives, and you conditionally
> close if conditions not in the same #if block, clang-format assumes the
> if conditions are never closed.
>
> example:
>
> #if HAVE_FOO
> if (something) {
> foo;
> if (otherthing) {
> foo;
> #endif
> #if HAVE_BAR
> if (newthing) {
> bar;
> if (newthing) {
> bar;
> #endif
> } else {
> errx(1, "Error: %s", bla);
> }
> }
>
>
> This could be an error with clang-format, or my mixture
> of versions (which otherwise works alright).
Though it is very likely an issue with current clang-format,
as it operates on tokens if I remember correctly. It is
reasonable to assume that what I did there is bad or
uncommon style and clang-format considers code between
directives.
> > If you require an entirely different style,
> > contributing to LibFormat and clang-format is an option.
> > I plant to do this with the outstanding KNF for NetBSD.
> >
> > As far as I know we weren't 100% okay with the results
> > for gnunet but already use it.
> >
> > > See in particular the following e-mails from the GNUnet discussion:
> > >
> > >
> > > On 4/15/19 10:02 AM, Schanzenbach, Martin wrote on [GNUnet-developers]:>
> > > Hi,
> > > >
> > > > FYI I added a clang-format at "contrib/conf/editors/clang-format".
> > > > Clang-format is usable with most editors (vim, emacs, vscode) with
> > > respective plugins.
> > > > This way, we can have a unified coding style.
> > > > Clang-format has a nice documentation and allows fine-grained setting
> > > which are also human readable:
> > > https://clang.llvm.org/docs/ClangFormatStyleOptions.html
> > > >
> > > > Let's use it and put it as a note into our coding guidelines?>
> > >
> > > Martin also wrote:
> > >
> > > > Most editors have plugins:
> > > >
> > > > emacs:
> > > https://llvm.org/svn/llvm-project/cfe/trunk/tools/clang-format/clang-format.el
> > > > (n)vim: https://github.com/rhysd/vim-clang-format
> > > > vscode: native
> > > > sublime: https://packagecontrol.io/packages/Clang%20Format
> > >
> > > And most recently I wrote (latest point of the discussion):
> > >
> > > >
> > > > Yes, the question is this: are there any developers here where their
> > > > editor cannot be reasonably integrated with clang-format? If so, please
> > > > do shout out now!
> > > >
> > > > I've so far heard only positive feedback for Martin's overall initiative
> > > > to get indentation under control, so for now I'll proceed with the
> > > > assumption that there are no blockers. But if you do have an issue with
> > > > this, please do let me know (on or off list) as soon as possible. If
> > > > there are no (sound) objections soon, I will give ng0/schanzen the
> > > > go-ahead to enable enforcement of clang formatting for all Git commits
> > > > in the future!
> > > >
> > > > Anyway, aside from the general policy debate, please read on for more
> > > > specific related issues.
> > > >
> > > > Deployment experience
> > > >
> > > > I had to install clang-format-9 from Debian experimental, as our
> > > > configuration includes options that are only in v9.
> > > >
> > > > For Emacs user's reference: Without v9, the Emacs integration silently
> > > > failed. I also had to create a symlink from clang-format to
> > > > clang-format-9, as the Emacs integration only looks for the clang-format
> > > > binary (and otherwise also fails silently).
> > > >
> > > >
> > > > Other than that, Emacs integration was straightforward:
> > > >
> > > > I added to gnunet/.dir-locals.el a hook on save (this may end up in Git
> > > > "soon")
> > > >
> > >
> > > > ((c-mode
> > > > (eval add-hook 'before-save-hook #'clang-format-buffer nil t)))
> > > > <<<
> > > >
> > > >
> > > > and to .emacs the logic to find the clang-format package
> > > >
> > >
> > > > (require 'package)
> > > > (add-to-list 'package-archives '("melpa" .
> > > > "https://melpa.org/packages/";))
> > > > ;; initialize package system
> > > > (package-initialize)
> > > > ;; actually load the package
> > > > (require 'clang-format)
> > > > <<<
> > > >
> > > > And of course also installed the clang-format package (
