Re: Any concrete plans after the GDB BoF?

[Andrew Burgess via Gdb <gdb@sourceware.org>]

Simon Marchi via Gdb <gdb@sourceware.org> writes:

> On 10/31/22 09:37, Joel Brobecker via Gdb wrote:
>>> I agree with all you said.  There is always some resistance related to
>>> how clang-format handles this or that case.  In my opinion, that's minor
>>> compared to the benefit of using it.  My opinion would be: make the
>>> clang-format config that is closest to our style today, make a big
>>> re-format, and carry on.
>> 
>> I agree with that. As long as the formatting is consistent, it might
>> take a little getting used to, but I think we'll be happier if we don't
>> have to spend time worrying about code formatting.
>> 
>> The one small obstacle, perhaps, might be if different versions of
>> the tool format things differently. In that case, we might have to
>> clearly state which version we expect the code to be formatted with.
>> I am thinking of the kind of issues we get with the configury which
>> is generated by the auto tools, which is so dependent on the version
>> that even the distro-provided versions introduce spurious differences
>> sometimes, as a result of which I have built my own set of vanilla
>> autotools. If clang-format is tricky to build, we may have issues
>> in that respect...
>
> 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.

My thinking is this; not every one is using a distro that quickly
packages the latest version.  This means that if we are always chasing
the latest version, at least some people will end up continually having
to build clang-format on a regular basis just so they can push to GDB.

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.

>
> So far I have never seen problems related to distro-specific patches, as
> we have seen with autoconf.
>
> For Debian/Ubuntu, it's easy to get the latest stable version through
> apt.llvm.org.  I don't really know about other distros.  In any case,
> it's easy to build and not long (not long like building the whole
> llvm/clang):
>
> $ git clone --depth 1 https://github.com/llvm/llvm-project.git --branch release/15.x
> $ mkdir -p llvm-project/build
> $ cd llvm-project/build
> $ cmake -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release -G "Unix Makefiles" ../llvm -DCMAKE_INSTALL_PREFIX=/tmp/llvm
> $ make -j 4 clang-format
> $ make install-clang-format
> $ /tmp/llvm/bin/clang-format --version
> clang-format version 15.0.4 (https://github.com/llvm/llvm-project.git 08bd84e8a6358eb412fcef279f8875e2d69a3374)

Could we build something like this into the GDB makefile maybe?  That
way folk don't need to go looking for this information.

Thanks,
Andrew


>
> Simon