Date: Sun, 02 Jun 2002 23:55:52 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Lyndon Nerenberg <lyndon@orthanc.ab.ca> Cc: jos@catnook.com, Sergey Babkin <babkin@bellatlantic.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: Improving GNU make compatibility in BSD make (+ patch) Message-ID: <3CFB12F8.2BFB09D2@mindspring.com> References: <200206030233.g532X8m1012565@orthanc.ab.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Lyndon Nerenberg wrote: > Writing portable makefiles is already enough of a pain in the ass. No. It's not. I've written Makefile's that predate the consolidation during and after The UNIX Wars; they run fine, unmodified, on 140 different vendor versions of UNIX. You are smearing the necessary distinctions between "mapping the problem space", "abstraction of complexity", and "non-intersection of mapping sets". All versions of "make" are attempts to map the same problem space. The more commands a "make" supports -- the richer the syntax it supports -- the more terse any given Makefile can be made to solve an arbitrary problem in the problem space. The more terse a Makefile, the higher its abstraction of the complexity of the problem to which it is being brought to bear. But each "make" has its own way of mapping the problem space; you can break the space into cubes, or you can break it into non-cubic trapezoids, or any of a number of elements of abstraction for a given space: and that gives you one mapping set. POSIX make semantics map the problem space, but they do so in a coarse fashion. What this means is that they are unable to be as terse as a make with a richer set of available mapping semantics (e.g. BSD make or GNU make). The upshot being that restricting yourself to POSIX make semantics means that your Makefile for an arbitrary problem will, with certain exceptions, end up being larger than a Makefile written to use additional features, above and beyond the POSIX features. In other words, a mapping set that is a superset of the POSIX mapping set -- or one, whose intersection with the POSIX mapping set is not the POSIX mapping set (i.e. it is missing some POSIX semantics). You need to be very careful with standards. When you build a mapping of a problem space, if that problem space is already mapped by a standard (e.g. POSIX), then you should minimally conform to the standard (conforming is defined as the standard set intersection with your implementations set yeilding the standard set). You also need to be very careful with extensions. Extensions, even in standards conforming implementations, are a problem in several ways: o If the standard is ever extended, there is a risk that your extension will conflict with the new instance of the standard. In general, revised standards will conform with existing standards (this is a definition for "revised standard" vs. "new standard"). o If your extensions are used, then software written to consume the standard interfaces is portable to your implementation, but software written to consume the interfaces exported by your implementation are *not* portable to other standards conformant implementations. In other words, you have attacked the standard through "embrace and extend", and you have encouraged the creation of non-compliant consumers of the standard defined interfaces. This is the basis of "The UNIX Wars", and it is also the basis of many people's complaints about Microsoft. o Your extensions may conflict with the extensions of third parties, which will damage the portability of the third parties application to your system. o Failure to adhere to standards damages the standards process by rendering standards meaningless in the face of defacto standards based, not on intelligent, informed consensus, but on market share. So ... why are we even having this discussion? Mostly, it's because people are too lazy to take their extensions to "make" syntax for finer granularity mapping of the problem space through the standards process, and want to make "defacto standards": "when you can't win fairly, cheat". I would still prefer that programs that need GNU make syntax use GNU make, and programs that need BSD make syntax use BSD make (and specifically, use the BSD make from the OP make source tree). If you are going to build non-standards-conforming Makefile's, at least be honest about the fact that they aren't conforming, and don't hide the origin of the non-conformance, so that you avoid conflicting future contributions as a result of conflicting divergence from the common superset of the standard (i.e. the attempted defacto standard end-run around the standards process). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CFB12F8.2BFB09D2>