bugmake - Bugs: bug #59584, ifeq with a space after the first...

 
 

bug #59584: ifeq with a space after the first open parenthesis

Submitted by:  None
Submitted on:  Tue 01 Dec 2020 03:55:44 AM UTC
 
Severity:  3 - Normal Item Group:  Enhancement
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  4.2.1 Operating System:  POSIX-Based
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       No canned response available

 

Sun 06 Dec 2020 06:48:06 PM UTC, comment #1: 

The reason this happens is that for conditionals, preceding whitespace is preserved in the left-hand side of the match, while trailing space is ignored.  Bizarrely, for the right-hand side of the match leading whitespace is ignored while trailing whitespace is preserved.

This gives the wholly unsupportable result that:

ifeq ( $(foo), $(foo))

is actually false, as is this:

ifeq ( $(foo),$(foo) )

while this is true:

ifeq ($(foo) , $(foo))

It's really frustrating to me how many of areas of makefile parsing paid insufficient attention to this issue of handling leading/trailing space.

It's well-defined in make variable assignment and in MOST other places in makefiles that leading whitespace is ignored and trailing whitespace is preserved, but there are various places where this was not done and we keep running into them bit by bit over time, after decades' worth of makefiles exist where who knows how many would break if we fixed the syntax to be consistent.

I always recommend to everyone that they remove all leading/trailing whitespace in all conditionals, as a simple to remember and always-correct rule.

I'll leave this open as an enhancement to consider addressing this in some way.

Paul D. Smith <psmith>
Project Administrator
Tue 01 Dec 2020 03:55:44 AM UTC, original submission:  

Seems like a space breaks the ifeq conditional.

Fedora: 32 5.8.13-200.fc32.x86_64
Make: 4.2.1

NB: The first and the last tests.

# The checks are for this variable being set to true.
using_thirdPartyLib=true

#confirmation. No trailing spaces
$(warning using_thirdPartyLib=[$(using_thirdPartyLib)] )

# THIS DOES NOT WORK!!!! due to the extra space after the open paren
ifeq ( $(using_thirdPartyLib),true)
my_c_flags = -I/home/3plibs/tplib/src
else
my_c_flags = UNSET
endif
$(warning conditonal using parens but WITH the extra space after open paren : my_c_flags=$(my_c_flags) )

my_c_flags =
# this works. No parens. Using quotes instead
ifeq "$(using_thirdPartyLib)" "true"
my_c_flags = -I/home/3plibs/tplib/src
else
my_c_flags = UNSET
endif
$(warning conditonal using double quotes and no parens and hence no space after open paren : my_c_flags=$(my_c_flags) )

my_c_flags =
# this works. No parens. Using quotes instead
ifeq '$(using_thirdPartyLib)' 'true'
my_c_flags = -I/home/3plibs/tplib/src
else
my_c_flags = UNSET
endif
$(warning conditonal using single quotes and no parens and hence no space after open paren : my_c_flags=$(my_c_flags) )

my_c_flags =
# this works as expected
ifeq ($(using_thirdPartyLib),true)
my_c_flags = -I/home/3plibs/tplib/src
else
my_c_flags = UNSET
endif
$(warning conditonal with parens but WITHOUT the extra space after open paren : my_c_flags=$(my_c_flags) )

my_c_flags =
# this test has the same space after the first paren but it actually works
ifneq ( $(using_thirdPartyLib),false)
$(warning using_thirdPartyLib=[$(using_thirdPartyLib)] )
my_c_flags = -I/home/3plibs/tplib/src
else
my_c_flags = UNSET
endif
$(warning ifneq conditonal with parens but WITH the extra space after open paren: my_c_flags=$(my_c_flags) )

all:

Anonymous

 

(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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-12-06 psmith Item GroupBug => Enhancement

    Back to the top


    Powered by Savane 3.9