bugmake - Bugs: bug #49093, ifdef checks for non-empty value,...

 
 

bug #49093: ifdef checks for non-empty value, not definition

Submitted by:  Danek Duvall <dduvall>
Submitted on:  Wed 14 Sep 2016 09:57:06 PM UTC  
 
Severity:  3 - Normal Item Group:  Documentation
Status:  Works for me Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  4.2.1 Operating System:  POSIX-Based
Fixed Release:  None Triage Status:  Small Effort

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Thu 15 Sep 2016 11:40:01 PM UTC, comment #3: 

I'm not asking for behavioral change -- I figured that would have been a long shot at best.  But I still feel like the docs are inconsistent, or at least could be clarified a bit.

Specifically, the sentences "Note that 'ifdef' only tests whether a variable has a value. It does not expand the variable to see if that value is nonempty." are, to my mind, incorrect, and not consistent with the earlier definition, or with the following examples.

In your first example here, FOO has a value, even if it's empty, so according to those sentences, it should evaluate to true.  I don't know whether that counts as "expansion", or whether "expansion" only matters when there's another variable for indirection, as in the second example.

Perhaps something like "Note that 'ifdef' only tests the named variable for a non-empty value, and does not further expand any variables it might reference." in place of those two sentences.  I'm not positive that would have told me what I needed to know, but I think it's a bit better than what's there now.

That said, I know the answer now, and this bug can be found if people search for ifdef and gnu make, so if you're averse to the change, perhaps that's enough.

Danek Duvall <dduvall>
Wed 14 Sep 2016 10:44:38 PM UTC, comment #2: 

Heh.  Philip Guenther points out such an example already exists in the manual.  I'm closing this bug.

Paul D. Smith <psmith>
Project Administrator
Wed 14 Sep 2016 10:13:25 PM UTC, comment #1: 

What the doc is trying to say is that:

FOO =
ifdef FOO
$(info true)
endif

will not print true because FOO has no value.

However, this:

FOO =
BAR = $(FOO)
ifdef BAR
$(info true)
endif

will print true.  Even though if you expanded $(BAR) you'd get the empty string, the variable BAR is not empty (it's set to $(FOO)) and so ifdef calls it defined.  Probably an example like this would help make the doc more clear.

Yes, it's true that ifdef is badly named.  It should be something like "ifset" or whatever instead.  However, it works as intended and so does the origin function value "undefined"; they have had these inconsistent meanings for 20+ years now; they're not going to change.

Paul D. Smith <psmith>
Project Administrator
Wed 14 Sep 2016 09:57:06 PM UTC, original submission:  

The info doc for "ifdef" is inconsistent.  It first says

    If the value of that variable has a non-empty value, the
    TEXT-IF-TRUE is effective

but then later says

    Note that 'ifdef' only tests whether a variable has a value.
    It does not expand the variable to see if that value is
    nonempty.

Perhaps I'm reading one of those two bits wrong?

At any rate, there seems to be a discrepancy in behavior between "ifdef" and $(origin).  Again, perhaps there's something I'm missing, but the following makefile demonstrates the issue.  If I leave VAR set to empty, then ifdef thinks VAR is undefined, but origin thinks it's defined.  If I set VAR to a non-empty value, both think it's defined.  If I remove the line entirely or add "undefine VAR", then both think it's undefined.  I see this behavior with 4.2.1 and with 3.82.

VAR=

ifdef VAR
$(info ifdef thinks VAR is defined)
else
$(info ifdef thinks VAR is undefined)
endif

ifneq "$(origin VAR)" "undefined"
$(info ifneq/origin thinks VAR is defined)
else
$(info ifneq/origin thinks VAR is undefined)
endif

all:

Danek Duvall <dduvall>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by dduvall (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-09-14 psmith StatusNone => Works for me
        Open/ClosedOpen => Closed
    2016-09-14 psmith Item GroupBug => Documentation
        Triage StatusNone => Small Effort

    Back to the top


    Powered by Savane 3.5