bugmake - Bugs: bug #59395, gmake space handling is not...

 
 

bug #59395: gmake space handling is not compatible to POSIX

Submitted by:  Jörg Schilling <schily>
Submitted on:  Sun 01 Nov 2020 07:41:16 PM UTC  
 
Severity:  3 - Normal Item Group:  None
Status:  Not A Bug Privacy:  Public
Assigned to:  Paul D. Smith <psmith> Open/Closed:  Closed
Component Version:  None Operating System:  None
Fixed Release:  None Triage Status:  None

Add a New Comment (Rich Markup)
   

You are not logged in

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

 

Tue 01 Dec 2020 06:07:57 PM UTC, comment #3: 

> Could you explain why gmake deviates from make in such an important point?


Is it important though?  What makefiles really care?  If it were critical then there would certainly be a lot of people upset about this but it seems like it only matters for the letter of the standard, not for any practical use.

The reason GNU make handles backslash/newline this way is lost in the mists of time so I cannot help you understand why it was done.  Most likely Richard and Roland just thought automatically condensing newlines was better / more user-friendly.  Their goal (AIUI) was not to perfectly emulate any other implementation of make: they wanted to create a make that worked best for them and their users.

Once the choice was made, and was in effect for a lot of years, there were potentially a lot of makefiles that assumed that whitespace was condensed (when showing output etc.) and it didn't seem important enough an issue to break backward-compatibility so when the POSIX discrepancy was pointed out I fixed it by changing it for .POSIX only.

The way it should have worked is to replace backslash/newline with ZERO characters.  That would have actually been a useful distinction because it would have allowed concatenation of text across lines (for formatting purposes in the makefile) without forcing spaces in them.  If you wanted a space you'd just include one before the backslash or after the newline, which almost everyone does anyway.  Once the opportunity to do it the right way was lost it seems fairly arbitrary whether you use one space per newline or collapse them into a single space.  In fact, the ONLY request I consistently get regarding handling of backslash/newline is how to avoid putting any spaces at all.  No one seems to care whether you get one space per newline or not.

> I believe that .POSIX should be reserved to cases where the POSIX standard does not agree with the behavior of the historic UNIX make.


I disagree with this interpretation of the purpose of .POSIX and see no justification for such an interpretation in the standard.  Its purpose is exactly what GNU make uses it for: to ensure that makefiles written to conform to the POSIX standard will work properly when run with a given make implementation.  Nothing more nor less.

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
Tue 01 Dec 2020 01:09:43 PM UTC, comment #2: 

Could you explain why gmake deviates from make in such
an important point?

I believe that .POSIX should be reserved to cases where the POSIX
standard does not agree with the behavior of the historic UNIX
make. This however does not apply to this case.

I fear that not fixing bugs in the default behavior could result in
an ecosystem of non-portable makefiles.

BTW: If there are really makefiles that depend on this bug, I
would prefer to see something line .GNU to enable the bugs
for unfixed makefiles.

Jörg Schilling <schily>
Fri 27 Nov 2020 04:54:04 PM UTC, comment #1: 

If you want POSIX behavior you have to define the .POSIX: special target; this makefile works as you expect with GNU make:

.POSIX:
all: ; echo "$X"
X=hallo\
\
\
end

Prints:

hallo   end

Note there's a bug #35711 which will bite you if you try to put the variable assignment directly after .POSIX:.  I have a fix for that which will be in the next release of GNU make.

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
Sun 01 Nov 2020 07:41:16 PM UTC, original submission:  

The following make file:

X=hallo\
\
\
end

all:
        echo "$X"

prints:

hallo end

while it should print:

hallo   end

like is happens when you use SunPro Make or smake.

Jörg Schilling <schily>

 

(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 schily (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-27 psmith StatusNone => Not A Bug
        Assigned toNone => psmith
        Open/ClosedOpen => Closed

    Back to the top


    Powered by Savane 3.7