Subject: Re: toolchain/15263: make(1) is willing to pick up .depend from too many locations
To: Paul Kranenburg <firstname.lastname@example.org>
From: None <email@example.com>
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
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"