Date: Sat, 22 Apr 1995 12:11:44 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: paul@isl.cf.ac.uk (Paul Richards) Cc: nate@trout.sri.MT.net, jkh@freefall.cdrom.com, hackers@freefall.cdrom.com Subject: Re: Any objection to adding a .undef(VARNAME) to make? Message-ID: <199504221911.MAA02245@gndrsh.aac.dev.com> In-Reply-To: <199504221907.UAA28460@isl.cf.ac.uk> from "Paul Richards" at Apr 22, 95 08:07:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
>
> In reply to Nate Williams who said
> >
> > > I've long been bothered by bmake's inability to programmatically unset
> > > a variable. Assuming that nobody feels it to be too evil a hack to
> > > live, are there any objections to using the keyword `.undef'?
> >
> > I'm kind of partial to '.undefine' myself, but I think the functionality
> > is a good addition to the utility. Too bad we couldn't find a way
> > similar to how something is defined to undefine it.
> >
> > FOO= 1
> >
> > FOO= undefined
>
> Anyone see a problem with FOO=
> Seems to make sense to me. How many things would that break?
Anything that tried to do a:
FOO=
.if defined(FOO)
BAR=${FOO}
.else
BAR=/usr/lib
.endif
would probably break. This behaves much differently than:
.undef FOO
.if defined(FOO)
BAR=${FOO}
.else
BAR=/usr/lib
.endif
Note this whole question become a non issue when I pointed out the
fact that our make alread has .undef implemented and tested to work.
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Custom computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504221911.MAA02245>