Any concrete plans after the GDB BoF?

Mark Wielaard mark@klomp.org
Sun Feb 12 12:43:45 GMT 2023


Hi Andrew,

On Sat, Feb 11, 2023 at 05:13:37PM +0000, Andrew Burgess wrote:
> Simon Marchi via Gdb <gdb@sourceware.org> writes:
> > I would suggest mandating one version, and for that version to
> > continuously be the latest stable version of clang-format, like we do
> > for Black.  When a new version comes out, we don't have to wonder if /
> > when we move the next version.  Someone just pushes a patch re-formating
> > the code to the next version, if there are some differences.  It keeps
> > the overhead to a minimum.
> 
> I dislike our policy of using the latest version of black, and would
> argue that always using the latest version _increases_ the overhead,
> rather than reducing it.

Have you found the python formatting flagged by black "unstable"?  The
buildbot uses the latest black as comes with fedora stable and I don't
remember it flagging issues on upgrades. But maybe it hasn't been
running for long enough? It has been running since July last year. Are
you running a much older black? Does it produce different formatting?
 
> If I had a choice then, personally, I'd vote against using clang-format
> at all, but it feels like there's a majority in favour, so if we do have
> to go down this route, I'd rather we adopted the same policy as for
> autotools and C++ versioning.  That is, pick something that works for
> us, and commit to it over the medium term.  That way at least, I can
> build a single version of clang-format and know that it's going to last
> me for a while.

But is there already a verions that works? I think that is the
difference between the python black formatter for python code and the
clang-format for C and C++ code. It seems for the python code there is
a supported format that matches what is used, but for clang-format
there is not (yet?).

Cheers,

Mark


More information about the Gdb mailing list