RE: Automatic code formatting

[<rsbecker@nexbridge.com>]

On July 10, 2022 8:59 PM, brian m. carlson wrote:
>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 gcc will *never* according to our latest intel, be supported on my platforms. *Never* is, of course, an indeterminate definition, but until various matters I cannot legally discuss change, which are not likely for at least 5 years, anything depending on gcc is out of the picture and unavailable, including clang. I understand the position regarding git contributions, but I am trying to get the point across that formatting code to a standard is a more general desire than just git contributions. It is a broad desire/requirement that should be considered. Rather than making processes git-contribution-specific, providing a more general solution that git contributors can use is more effective.

--Randall