Date: Tue, 19 Feb 2002 14:40:02 -0800 (PST) From: "Crist J. Clark" <cjc@FreeBSD.ORG> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/35119: make(1) variable modifier bug (:L, :U etc) Message-ID: <200202192240.g1JMe2L18033@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/35119; it has been noted by GNATS.
From: "Crist J. Clark" <cjc@FreeBSD.ORG>
To: "Simon 'corecode' Schubert" <corecode@corecode.ath.cx>
Cc: bug-followup@FreeBSD.ORG
Subject: Re: bin/35119: make(1) variable modifier bug (:L, :U etc)
Date: Tue, 19 Feb 2002 14:33:41 -0800
On Tue, Feb 19, 2002 at 12:50:02PM -0800, Simon 'corecode' Schubert wrote:
> On Tue, 19 Feb 2002 16:47:38 +0100 (CET) stijn@win.tue.nl wrote:
>
> > make(1) has a buglet wrt expanding variables with modifiers. If an
> > expansion of an undefined variable, with a modifier, is used in an .if
> > statement like so:
> >
> > .if defined(FOO) && ${FOO:L} == "bar"
> >
> > make bombs out with a 'Malformed conditional', even if FOO is not
> > defined.
>
> i believe this is already known. make processes all statements on an .if line, no matter if this is needed or not (unlike most other languages):
The problem is that this behavior contradicts the documented
behavior. make(1) says,
As in C, make will only evaluate a conditional as far as is necessary to
determine its value.
But as you say, this is known behavior, PR bin/34032. A patch is
included in that PR's audit trail. Would the submitter please check if
that patch solve's his problems? I'm looking to commit that
soon, but not 100% sure the logic is totally sound. Another successful
test would help. Thanks.
I will close up this PR as a duplicate.
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202192240.g1JMe2L18033>