Re: Automatic code formatting

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 3586 bytes --]

On 2022-07-10 at 22:13:01, rsbecker@nexbridge.com wrote:
> 
> Being one of the platforms that will be specifically excluded from
> this proposal, I would like to offer an alternative. Before that,
> please remember that not everything is Linux. My suggestion is to
> create infrastructure to automatically format on add/commit. This
> could be pluggable relatively simply with clean filter that is
> language specific - perhaps with a helper option that installs the
> formatter easily (because clean filters are notoriously painful to
> install for newbies from my observations). It would be nice to have
> something in perl that is more portable and pervasive than clang -
> although perl could launch clang where available. I think having
> infrastructure for code formatting that is built into git is actually
> highly desirable - assuming that it is not unduly difficult to install
> those. It would extend beyond git contributions, but the contributors
> could be told (Contributor's Guide) that then need to follow standard
> X, which may very well be clang format. There are java formatters, php
> and perl formatters, even COBOL and TAL formatters. My position is
> that having a standard way to plug these in is a more general plan
> that would reach a larger community. Git contributions could then just
> leverage standard git functionality.

I am willing to acknowledge the fact that not everybody has clang on their
preferred platform.  However, I assume you do have a laptop or desktop
with which you access your platform (since I believe it's a server
platform) and that you can install software there, or that you have the
ability to run some sort of virtualization framework on some system.

I am in general not very willing to say that we can't use or have useful
developer tools because of uncommon platforms.  Linux, Windows, macOS,
and (I believe) FreeBSD, NetBSD, and OpenBSD all support clang and
related tools, and I don't think it's unreasonable for us to expect that
someone can have access to such a system as part of development, even if
that's in a VM.  Those six operating systems plus Chrome OS constitute
the overwhelming majority of desktop and laptop systems, and there are
several options which are free (both as in speech and beer).

Moreover, clang and LLVM are extremely portable[0].  As a practical
matter, any platform wanting to support software written in Rust (a
popular and growing language) will likely need LLVM, and there is also a
lot of software in C and C++ that only supports GCC-compatible
compilers.  I do feel that providing support for modern toolchains is an
important part of providing a viable OS port, and that we should be able
to rely on porters for that OS to do that work.  I realize that LLVM is
not yet ported to your system, but I believe it's going to functionally
need to happen sooner or later.  When it does, you'll be able to send
patches directly without needing to copy to another OS to format the
code.

I should point out that I'm very willing to accept less common platforms
or architectures as build targets provided they can support the 2008
version of POSIX (which was released 14 years ago) reasonably well.  I
feel strongly that we should continue to support such systems for the
indefinite future to the best of our abilities.

[0] LLVM supports targeting 18 Debian architectures under Linux, Haiku,
VXWorks, Fuchsia, UEFI, WebAssembly, NVidia CUDA, the Nintendo 3DS, and
more.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]