NetBSD Problem Report #15178

Received: (qmail 14964 invoked from network); 8 Jan 2002 13:03:43 -0000
Message-Id: <200201081302.g08D2qM10742@sam.few.eur.nl>
Date: Tue, 8 Jan 2002 14:02:52 +0100 (MET)
From: Paul Kranenburg <pk@cs.few.eur.nl>
Reply-To: pk@cs.few.eur.nl
To: gnats-bugs@gnats.netbsd.org
Subject: make(1) looks for `.include' files in wrong places
X-Send-Pr-Version: 3.95

>Number:         15178
>Category:       toolchain
>Synopsis:       make(1) looks for `.include' files in wrong places
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    toolchain-manager
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 08 13:04:00 +0000 2002
>Closed-Date:    Sat May 07 21:40:31 +0000 2022
>Last-Modified:  Sat May 07 21:40:31 +0000 2022
>Originator:     Paul Kranenburg
>Release:        NetBSD-current Jan 2002
>Organization:

>Environment:

>Description:
	make(1) goofs when constructing file system paths to search for 
	makefiles to be included using the `.include' syntax.

		- when object dirs are in use or nested includes nested
		  includes are being processed involving files not
		  residing in .CURDIR, make(1) constructs path by
		  prepending .CURDIR twice!
		- inclusion of an absolute path name (e.g. /etc/mk.conf)
		  still causes it to be searched first relative to all
		  include directories make knows about.
>How-To-Repeat:
	run `make -dA' on any Makefile using .include.
>Fix:
	none provided.
	Yet I note that these particular problems (but not those mentioned
	in PR15163) appeared with revision 1.27 of src/usr.bin/make/dir.c
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: bin-bug-people->toolchain-manager 
Responsible-Changed-By: gnats 
Responsible-Changed-When: Tue Feb 12 00:58:26 PST 2002 
Responsible-Changed-Why:  
There is now a "toolchain-manager" which is the proper default role 
account for handling problem reports in the toolchain category. 

State-Changed-From-To: open->closed
State-Changed-By: rillig@NetBSD.org
State-Changed-When: Sat, 07 May 2022 21:40:31 +0000
State-Changed-Why:
I could not reproduce the claim about .CURDIR being prepended twice.
Neither with current make nor with any from 2002 or 2001.

Searching for absolute filenames has been fixed in 2002.01.26.22.36.41.


>Unformatted:

Home	PR Database Search