Check whether a macro is undefined or has a specific value

Marco listaddr at
Thu Aug 18 08:12:43 UTC 2011

2011/8/17 Daniel Neuberger <daniel.neuberger at>:
> On 08/16/2011 12:26 PM, Marco wrote:
>> Thanks. I don't need to define another macro based on the value of
>> %{__foo}. However based on your suggestion, I think I can do this,
>> which seems to work:
>> %if %{?__foo:1}%{!?__foo:0}
>> %if "%{__foo}" == "1"
>>   echo "foo is defined and is 1"
>> %else
>>   echo "foo is defined, but has some other value: %{__foo}"
>> %endif
>> %else
>>   echo "foo is not defined"
>> %endif
>> Does this look correct/reliable enough or is there a better way to do
>> what I'm trying to do? Thanks.
> I've never found documentation with the specifics of the %if macro, so
> testing to see what works is the best method I know.  It seems like the
> above works.  If you all need "do something" and "skip" block, the below is
> less verbose:
> %if "%{?__foo:%{__foo}}%{!?__foo:0}" == "1"
>  echo "foo is defined and is 1"
> %else
>  echo "foo is not defined or not equal to 1"
> %endif

Ah thanks, I hadn't thought of this.

> Alternatively, you could also define a macro that expands to the "do
> something" when needed, and expands to nothing otherwise.  I don't know of
> simpler way to check equality though (but I'm kind of new to this stuff
> too).
> Out of curiosity (if you don't mind me asking), why do you need to check
> both for definition and equality?  What are you trying to do?

Sure. It's just that rpmbuild will be called from people's makefile,
where they are supposed to run it by doing rpmbuild ... --define
'__foo 1' if they want some special functionality to be enabled, and
define it to 0 if not. Despite having been told this, I'm 100% sure
that what will happen is that some people will define it correctly,
some will do --define '__foo 0', some will not bother defining it (or
will plain forget), possibly others will do yet other variations
(typos, --define '__foo TRUE' or whatever), so I want to make sure
that only those who really mean it get the functionality, while all
the others will not get it but it should not break the build with
parsing errors (and being able to differentiate in the spec file among
the cases may help me give better error message or take more
appropriate actions if I will need to).


More information about the Rpm-list mailing list