Re: make -U
From: Ruslan Ermilov (ru_at_FreeBSD.org)
Date: 08/02/03
- Previous message: Robert Watson: "Re: headsup: swap_pager.c"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 2 Aug 2003 20:13:52 +0300 To: Faried Nawaz <fn@hungry.com>
[ Moved to -arch ]
> From the message in freebsd-hackers which first introduced
> this patch:
>
> - Date: Tue, 29 Jul 2003 09:09:17 -0700
> - From: Faried Nawaz <fn@hungry.com>
> - Subject: patch to add make -U
>
> 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.
>
> http://web.nilpotent.org/tmp/make.diff.bz2 (~ 3KB unpacked)
> against yesterday's -CURRENT code.
>
The patch looks sane.
> A simple Makefile I used to test it:
>
> -- cut here --
> FOO = bar
>
> .ifdef FOO
> SAY = y
> .else
> SAY = n
> .endif
>
> all:
> echo $(SAY)
> -- cut here --
>
> Try "make -U FOO".
>
> 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.
>
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
from 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,
-- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software Ltd, ru@FreeBSD.org FreeBSD committer
- application/pgp-signature attachment: stored
- Previous message: Robert Watson: "Re: headsup: swap_pager.c"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: [PATCH] module_author: dont advice putting in an email address
... Adrian Bunk had a valid argument against it and it's one of the arguments that exist against
MODULE_AUTHOR as well; the address would live on "forever" as part of Linux installs. ...
Then the dog eats my foo and I can't maintain it anymore since I can't test; off goes a patch
removing MODULE_MAINTAINER from the source and/or the MAINTAINERS file but I can't do anything about
all the existing installs that proudly announce my address as a contact for foo. ... The advice
of putting in an email address is generally bad advice. ... (Linux-Kernel) - Re: a relatively major problem with ext2.
... On 3/9/05, Peter Edwards wrote: ... The patch still applies in today's
... # rm -rf foo ... (freebsd-current) - Re: [PATCH 9/36] drivers edac new intel 5000X mc driver
... Here's a small patch against v.3 that will catch this. ... already has checks
for reporting the foo ** bar style cast format ... it is hard to tell them from
the foo * foo multiply form, ... (Linux-Kernel) - Re: [PATCH 4/6] Implement a general log2 facility in the kernel
... Considering that several arch maintainers have vetoed my patch to revert ...
int log2(int foo) ... Don't re-use C standard library identifiers ... (Linux-Kernel)