From owner-freebsd-hackers Sat Dec 2 15:24:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA14396 for hackers-outgoing; Sat, 2 Dec 1995 15:24:48 -0800 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA14374 for ; Sat, 2 Dec 1995 15:24:36 -0800 Received: from exalt.x.org by expo.x.org id AA02711; Sat, 2 Dec 95 18:24:02 -0500 Received: from localhost by exalt.x.org id XAA14699; Sat, 2 Dec 1995 23:24:02 GMT Message-Id: <199512022324.XAA14699@exalt.x.org> To: hackers@freefall.FreeBSD.org Subject: Re: Minor change to make In-Reply-To: Your message of Sat, 02 Dec 1995 13:53:19 EDT. <199512022153.NAA18484@multivac.orthanc.com> Organization: X Consortium Date: Sat, 02 Dec 1995 18:24:01 EDT From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Is is possible for you to use the ".if !exists(...)" construct > instead? As long as you know the path (relative or absolute) to > the include this should solve the problem without introducing > an incompatible change to make. It happens to work, but I don't see it as equivalent. According to the man page `.if exists(file)' has different file search semantics than `.include "file"'. How do I know someone won't put 'depend.mk' in /usr/share/mk some day? I just don't feel that lucky. :-) Nor do I agree that this is an incompatible change, and that not withstanding I did say that I was willing to do the work to add this functionality as a new feature that would preserve the legacy behavior. I know hacking make isn't as sexy as writing file systems, schedulers, MS-DOS emulators, and linux binary compat; but I don't understand the resistance to adding this? For as many times as I build X, it would save a bunch of time for me if I didn't have to rebuild the dependencies every time I remake the Makefile because I am able to preserve them in an include file. If it's useful to me I'm sure it'd be useful to someone else too. -- Kaleb KEITHLEY X Consortium