Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 2 Aug 2003 20:13:52 +0300
From:      Ruslan Ermilov <ru@FreeBSD.org>
To:        Faried Nawaz <fn@hungry.com>
Cc:        arch@FreeBSD.org
Subject:   Re: make -U
Message-ID:  <20030802171352.GA36129@sunbay.com>
In-Reply-To: <p052106acbb4f3e74d79a@[128.113.24.47]>
References:  <20030730212049.GI33188@sunbay.com> <20030730162320.A66578@FreeBSD.org> <20030730212744.GJ33188@sunbay.com> <20030730163705.A68092@FreeBSD.org> <bgb67e$12kl$1@kemoauc.mips.inka.de> <p052106acbb4f3e74d79a@[128.113.24.47]>

next in thread | previous in thread | raw e-mail | index | archive | help

--dDRMvlgZJXvWKvBx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[ Moved to -arch ]

> From the message in freebsd-hackers which first introduced
> this patch:
>=20
> - Date: Tue, 29 Jul 2003 09:09:17 -0700
> - From: Faried Nawaz <fn@hungry.com>
> - Subject: patch to add make -U
>=20
>     While working around a port issue (ports/55013), I discovered
>     that make couldn't unset variables using make -U.  I've written
>     a small patch that adds -U functionality, but I haven't tested
>     it extensively.
>=20
>     http://web.nilpotent.org/tmp/make.diff.bz2  (~ 3KB unpacked)
>     against yesterday's -CURRENT code.
>=20
The patch looks sane.

>     A simple Makefile I used to test it:
>=20
>     -- cut here --
>     FOO =3D bar
>=20
>     .ifdef FOO
>     SAY =3D y
>     .else
>     SAY =3D n
>     .endif
>=20
>     all:
>    	echo $(SAY)
>     -- cut here --
>=20
>     Try "make -U FOO".
>=20
> Personally I think this is a reasonable option to implement.
> An undefined variable is not the same as a variable which is
> defined to be a null string.
>=20
I want that everyone understands the effect of the patch: the
-U FOO option causes the FOO variable to always be reported
by make(1) as undefined, not only in this makefile, but even
in sub-make processes, and affects all makefiles wishing to
set it -- it just doesn't let them do this, globally.

So the actual meaning of this option is "prevent variable FOO
=66rom being set".  (The implementation is somewhat different;
it causes make(1) to lie that variable being is, but the net
effect is the same.)

Given the above, do we really want this option in our make?


Cheers,
--=20
Ruslan Ermilov		Sysadmin and DBA,
ru@sunbay.com		Sunbay Software Ltd,
ru@FreeBSD.org		FreeBSD committer

--dDRMvlgZJXvWKvBx
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE/K/FQUkv4P6juNwoRAo38AJ4wsIqLvP9XYPa5EM93/fZYeio+zwCgiITa
oxuryPizIgJFkhdQIIUgbmU=
=K3iD
-----END PGP SIGNATURE-----

--dDRMvlgZJXvWKvBx--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030802171352.GA36129>