On 2022-07-10 at 22:13:01, rsbecker@xxxxxxxxxxxxx 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:
signature.asc
Description: PGP signature
