Re: Replacing fixcc.py with clang-format?

[Luca Fascione]

Side thought: if your CPP code is complex, indenting it helps readability a
lot, here's a goofy example

#if CONDITION
#  define AMACRO 6
#  include "some/file.h"
#else
#  if WIN32
#    include "something/else.h"
#  elif MACOSX
#    include "the/darwin/version.h"
#  endif
#endif

I haven't seen clang-format formats that do this before, but on my code I'd
have it leave CPP code alone if it didn't do this

L

On Tue, 6 Sep 2022, 20:56 Jonas Hahnfeld via Discussions on LilyPond
development, <lilypond-devel@gnu.org> wrote:

> On Tue, 2022-09-06 at 18:46 +0200, Jean Abou Samra wrote:
> > There's one thing I'd like to discuss now, for the reformatting round
> > before we do the branching.
>
> (Yes, I didn't manage yet to propose the reformatting. I'd like to do
> this after 2.23.13 is released. As a reminder, the idea is that we
> introduce a bit of churn before branching, but then don't get into
> trouble when backporting fixes to the branch.)
>
> > I would like to propose moving to clang-format as the canonical
> > formatting tool and removing fixcc.py. This will decrease our
> > maintenance burden. fixcc.py is more than 600 lines of code to
> > maintain.
>
> In general I'm not opposed. However, please note that clang-format is
> sometimes not stable over time, ie new versions can change formatting.
> Most projects use git-clang-format to incrementally format only the
> lines touched by commits. In LilyPond, the current practice is to
> format all code files, so we will experience this to its fullest. I
> don't know if that's going to be a problem, but I thought I'd mention
> it.
>
> > These days, git blame supports the --ignore-rev option, which makes
> > this less painful for future code historians.
>
> We can also have a .git-blame-ignore-revs in the repository. This
> already works on GitHub, and there is an open issue to also support it
> in GitLab: https://gitlab.com/gitlab-org/gitlab/-/issues/31423
>
> > It will obviously still produce merge conflicts with existing WIP
> branches.
>
> Usually branches can be "updated" by also running the (same) formatting
> tool on the changes, and then either git manages to resolve things
> itself or you can "port" the diff.
>
>