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

[Danek Duvall]

Follow-up Comment #3, bug #49093 (project make):

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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul Smith]

On Wed, 2016-09-14 at 15:16 -0700, Philip Guenther wrote:
> On Wed, Sep 14, 2016 at 3:13 PM, Paul D. Smith  
> wrote:
> ...
> > Probably an example like this would help make the doc more clear.
> 
> There *is* an example like that in the doc in at least version 4.2.1!

Oh.  Yeah.  Hah!

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

Update of bug #49093 (project make):

  Status:None => Works for me   
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

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

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Philip Guenther]

On Wed, Sep 14, 2016 at 3:13 PM, Paul D. Smith  wrote:
...
> Probably an example like this would help make the doc more clear.

There *is* an example like that in the doc in at least version 4.2.1!

 Note that `ifdef' only tests whether a variable has a value.  It
 does not expand the variable to see if that value is nonempty.
 Consequently, tests using `ifdef' return true for all definitions
 except those like `foo ='.  To test for an empty value, use
 `ifeq ($(foo),)'.  For example,

  bar =
  foo = $(bar)
  ifdef foo
  frobozz = yes
  else
  frobozz = no
  endif

 sets `frobozz' to `yes', while:

  foo =
  ifdef foo
  frobozz = yes
  else
  frobozz = no
  endif

 sets `frobozz' to `no'.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

Update of bug #49093 (project make):

  Item Group: Bug => Documentation  
   Triage Status:None => Small Effort   

___

Follow-up 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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Danek Duvall]

URL:
  

 Summary: ifdef checks for non-empty value, not definition
 Project: make
Submitted by: dduvall
Submitted on: Wed 14 Sep 2016 09:57:06 PM GMT
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.2.1
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None

___

Details:

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:




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make