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


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

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

Add a New Comment Rich Markup

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>
Group administrator
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:

all: ; echo "$X"


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>
Group administrator
Sun 01 Nov 2020 07:41:16 PM UTC, original submission:  

The following make file:


        echo "$X"


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:

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)

    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.


    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.12.
    Corresponding source code