bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unable to build git@7774cfed62 using make@033330e


From: Martin Dorey
Subject: Re: Unable to build git@7774cfed62 using make@033330e
Date: Thu, 4 Apr 2024 18:24:13 +0000

I'm afraid it's a bug in git's config.mak.uname.  To point at one example, I think of many:


... starts with a tab but, this human is reasonably confident, from eg the indentation, that it's intended as Make syntax rather than shell script.  "else" is common in shell script and in Gnu Make.  When Make's parser sees one in a rule's "recipe", how's it to decide whether it's for the shell or for Make?  According to the Make documentation, it's determined by whether the line starts with a tab.  That's clear, simple and imo what someone new to the beast would guess but the implementation in Make wasn't previously rigorous.

This came up recently in the Linux kernel build system, resulting in:


In finding that, I see that poor Yamada-san caught an earful:


I fear we should have led with the "else" explanation, as I did above.  The Make check-in:


... mentions "SV 64815" and its patch mentions "SV 64085", neither of which were right:

https://savannah.gnu.org/bugs/?64815: gxditview renders '\-' as '-' (a short line segment like a hyphen)
https://savannah.gnu.org/bugs/?64085: -e passed to shell in POSIX mode with -i or .IGNORE

The intended Make bug was:

https://savannah.gnu.org/bugs/?64185: *** only one 'else' per conditional. Stop. due to else in recipe


From: bug-make-bounces+martin.dorey=hds.com@gnu.org <bug-make-bounces+martin.dorey=hds.com@gnu.org> on behalf of Dario Gjorgjevski <dario.gjorgjevski@gmail.com>
Sent: Thursday, April 4, 2024 06:41
To: bug-make@gnu.org <bug-make@gnu.org>
Subject: Unable to build git@7774cfed62 using make@033330e
 
***** EXTERNAL EMAIL *****

Attempting to build git@7774cfed62 using make@033330e results in a
missing 'endif' at the end of config.mak.uname:

config.mak.uname:842: *** missing 'endif'.  Stop.

Permalink to config.mak.uname:
https://nam04.safelinks.protection.outlook.com/?url="">.
(Included from Makefile:
https://nam04.safelinks.protection.outlook.com/?url="">
As far as I can see, both git's Makefile and config.mak.uname look
good.  The latest tagged release of make, 4.4.1, has no problems with
it, and neither does the make shipped with macOS.

Best regards,
Dario


reply via email to

[Prev in Thread] Current Thread [Next in Thread]