Subject: Re: toolchain/15263: make(1) is willing to pick up .depend from too many locations
To: Paul Kranenburg <pk@cs.few.eur.nl>
From: None <kpneal@pobox.com>
List: tech-toolchain
Date: 01/16/2002 22:30:05
On Wed, Jan 16, 2002 at 03:33:48PM +0100, Paul Kranenburg wrote:
> When looking for a .depend file, and finding none in the object
> directory, make(1) will look elsewhere for one along the current
> search directory paths, i.e. .CURDIR, any -I specified paths and
> finally in even in the system directory (usually /usr/share/mk).
> This behaviour is not mentioned in the make documentation and its
> usefulness is questionable. If ever a stray .depend appears in
> the search path, confusing failures may result.
Ok, that sounds confusing.
> The same is true, btw., for the search for `makefile' and `Makefile'.
> E.g. a stray `makefile' in the object directory takes precedence over
> a `Makefile' in the source directory, and there's also hardly any
> need for a system-wide /usr/share/mk/Makefile..
Uh, please don't change this.
I can see the usefulness in having a makefile be generated in the object
directory be picked up. Imagine doing a 'make makefiles' and specifying
a makefile with -f the first time. After that the generated makefile
in the object directory will be picked up and no -f is needed on the
command line.
As for /usr/share/mk/Makefile: imagine making an empty directory and
then doing a 'make setup-my-playpen'. Poof, a user can configure
a playpen without using any commands other than make.
This is actually functionality that I can use at my day job. We
don't use NetBSD make yet, but I'm working on moving us towards
it. Please don't slide NetBSD make out from underneath me.
--
Kevin P. Neal http://www.pobox.com/~kpn/
"It sounded pretty good, but it's hard to tell how it will work out
in practice." -- Dennis Ritchie, ~1977, "Summary of a DEC 32-bit machine"