Date: Mon, 4 Dec 1995 12:37:49 +0100 (MET) From: grog@lemis.de (Greg Lehey) To: kaleb@x.org (Kaleb S. KEITHLEY) Cc: hackers@freebsd.org (FreeBSD Hackers) Subject: Re: Minor change to make Message-ID: <199512041137.MAA09697@allegro.lemis.de> In-Reply-To: <199512022324.XAA14699@exalt.x.org> from "Kaleb S. KEITHLEY" at Dec 2, 95 06:24:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512041137.MAA09697>