From owner-freebsd-hackers Mon Dec 4 03:59:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA25149 for hackers-outgoing; Mon, 4 Dec 1995 03:59:34 -0800 Received: from cls.net (freeside.cls.de [192.129.50.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id DAA25095 for ; Mon, 4 Dec 1995 03:59:12 -0800 Received: by mail.cls.net (Smail3.1.29.1) from allegro.lemis.de (192.109.197.134) with smtp id ; Mon, 4 Dec 95 11:59 GMT From: grog@lemis.de (Greg Lehey) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Reply-To: grog@lemis.de (Greg Lehey) Received: (grog@localhost) by allegro.lemis.de (8.6.9/8.6.9) id MAA09697; Mon, 4 Dec 1995 12:37:50 +0100 Message-Id: <199512041137.MAA09697@allegro.lemis.de> Subject: Re: Minor change to make To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Mon, 4 Dec 1995 12:37:49 +0100 (MET) Cc: hackers@freebsd.org (FreeBSD Hackers) In-Reply-To: <199512022324.XAA14699@exalt.x.org> from "Kaleb S. KEITHLEY" at Dec 2, 95 06:24:01 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2750 Sender: owner-hackers@freebsd.org Precedence: bulk Kaleb S. KEITHLEY writes: > >> 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. :-) Another reason not to do this is that some makes--GNU make, at least--are clever enough to make an include file if they find a rule. For example, I have a Makefile with: include book.make book.make: Makefile makebookmakefile ./makebookmakefile ${POSTSCRIPT} In other words, the fact that the file doesn't exist is no reason not to be able to include it. > 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. That depends on what you want to be compatible with. I think Jordan made a good point that it might break the kernel build. In my book, that is definitely an incompatibility. > 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. I'm not sure what you're saying here. If you remake the Makefile, for example after changing the Imakefile, there is a good chance that the new Makefile will be different. As a result, the dependencies may change too. To be really honest, you should ensure that *everything* depends on the Makefile. The only clean way I can think of avoiding these problems is to build a Makefile.new, compare the two, and if they're different, mv Makefile.new to Makefile. That way you can be sure that, if there is any difference, the Makefile will change. Then you include your dependencies: include depend depend: Makefile makedepend etc This, of course, expects GNU make or another one which can create its own include files. Which brings me to another suggestion: why not add *that* facility to FreeBSD (p)make? That way you can create dummy files if you don't mind them not existing. It should be more compatible, but I don't know if the existence of dummy files would be acceptable. Greg