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"