From owner-freebsd-hackers Sat Jun 1 15:10:31 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by hub.freebsd.org (Postfix) with ESMTP id 8F18537B404 for ; Sat, 1 Jun 2002 15:09:33 -0700 (PDT) Received: from pool0150.cvx21-bradley.dialup.earthlink.net ([209.179.192.150] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17EH3w-0007RK-00; Sat, 01 Jun 2002 15:09:28 -0700 Message-ID: <3CF945F8.510D2F1D@mindspring.com> Date: Sat, 01 Jun 2002 15:08:56 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: jos@catnook.com Cc: freebsd-hackers Subject: Re: Improving GNU make compatibility in BSD make (+ patch) References: <20020601015343.GA1132@lizzy.catnook.com> <20020601181529.GD13397@lizzy.catnook.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jos Backus wrote: > On Sat, Jun 01, 2002 at 11:45:15AM -0600, Ian wrote: > > Actually, I think it's a great idea. It should make life much easier for > > people creating and maintaining ports. > > My thoughts exactly. Any port that switches to BSD make because the Makefile uses this *one* GNU make specific feature, and it becomes implemented in BSD make, is just asking for it. Any existing port maintainer doing a proper risk analysis will not fall into this trap. A maintainer of a new port *might* have marginal benefit (which I would argue would be transient, at best) IFF this is the only GNU make specific feature that the Makefile uses (this is a small subset of potential work). You are assuming that someone who uses one GNU make specific feature now, will not use more GNU make specific features in future versions of their code, going forward. I would argue that this is a low probability bet: o They are already using GNU make as their baseline for selection of which features they are going to exploit o The have implicitly demonstrated their lack of care for portability in their use of the feature in the first place o Programmers naturally gravitate towards use of more and more esoteric features of tools as they learn to use their tools o We have to assume that GNU make is at least moderately well designed for this discussion -- if it isn't, it would be a bad idea to imitate it -- and so the other features it implements but BSD make does not also have their purpose within that design. This will promote their use by programmers The most likely outcome is that the maintainer for the original GNU make specific code will include more GNU make specific features in the Makefiles, over time, going forward. When this happens, the port maintainer will be faced with one of two options: A) Switch the port back to GNU make, wasting the work they did to switch it to BSD make in the first place B) Modify the BSD make to implement the newly used GNU make feature, so that the port does not have to be switched Both of these options are effort intensive. Both of them entail work that would not be necessary, had the porter simply made the port depend on the GNU make port ("gmake"), like all other similar ports currently do. If you want to make the argument that implementation of GNU features in all tools and/or a switch to GNU tools would result in more software being available for FreeBSD: make that argument, don't try to approach it tangentially and sneak the idea in under everyone's radar. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message