From owner-freebsd-bugs Wed Nov 7 20:30: 7 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0D01637B41B for ; Wed, 7 Nov 2001 20:30:03 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id fA84U3172239; Wed, 7 Nov 2001 20:30:03 -0800 (PST) (envelope-from gnats) Date: Wed, 7 Nov 2001 20:30:03 -0800 (PST) Message-Id: <200111080430.fA84U3172239@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Matthew Emmerton" Subject: Re: bin/24377: make(1) does not correctly substitute in internal macros like $(@F:.o=.c) Reply-To: "Matthew Emmerton" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR bin/24377; it has been noted by GNATS. From: "Matthew Emmerton" To: , Cc: Subject: Re: bin/24377: make(1) does not correctly substitute in internal macros like $(@F:.o=.c) Date: Wed, 7 Nov 2001 23:27:04 -0500 Here's a patch to the 4.3-REL version of make to fix this problem. It's been tested with the example case in the PR. Basically, after expanding F or D, we fall-through to the expansion code, rather than returning right away. --- var.c.orig Wed Nov 7 23:13:29 2001 +++ var.c Wed Nov 7 23:12:39 2001 @@ -1622,8 +1622,6 @@ *freePtr = TRUE; *lengthPtr = tstr-start+1; *tstr = endc; - Buf_Destroy(buf, TRUE); - return(val); } break; } -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message