Re: Any concrete plans after the GDB BoF?
Mark Wielaard <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Andrew, On Sat, Feb 11, 2023 at 05:13:37PM +0000, Andrew Burgess wrote: > Simon Marchi via Gdb <[email protected]> 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