On Fri, May 10, 2024 at 1:57 AM Paul Smith <[email protected]> wrote: > > On Mon, 2024-05-06 at 13:47 -0400, Alfred M. Szmidt wrote: > > I was referring to the GNU Coding Standard manual > > > > It is portable across GNU systems, other systems are not a high > > priority. The mission of the GNU project is to develop the GNU > > system after all, and the GNU Coding Standards document that. > > Sorry Alfred but I can't agree with your statements here. > > The entire reason that the FSF and GNU project expend so much energy > and time on things like autotools and gnulib, is exactly so that GNU > projects can, with relatively little effort, be portable to non-GNU > systems. We absolutely DO care, a lot, about this and the GNU coding > standards are intended to reinforce this portability, not just hardware > portability. > > If all we cared about was portability to GNU systems we could do away > with 99% of autotools and gnulib; basically everything except > portability between older and newer versions of glibc-based systems.
Perhaps I should state my expectations here. The GNU Coding Standards may be referenced by many people, including those who don't develop any GNU software. Many coding standards around the web would document _why_ the code is written in one style and not the others. Even people who _hate_ GNU Coding Standards would have reasons why a particular GNU style wouldn't be used, and what alternatives are preferred instead. For this particular makefile ’$<’ example, I expect it would be one of these reasons: 1. The 'make' implementations that do not support '$<' in ordinary (not inference) rules are too rare or too old to support; or 2. (A future version of) Automake might automatically substitute '$<' in makefiles to ensure portability so that developers don't need to address this portability issue themselves; or 3. Something else. Which reason it is then?
