GNU bug report logs - #46052
Colons fooling GNUmakefile mode

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 46052 in the body.
You can then email your comments to 46052 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Colons fooling GNUmakefile mode
Date: Fri, 22 Jan 2021 21:27:32 +0800

Colons on lines 2 and 4 shouldn't change the line color:
$ cat Makefile
eee:
	set -x; $c 11999 3555; $c 11999 3355; :
	set -x; $c 9999   999; $c 9999   799;
	set -x; $c 8499  1606; $c 8499   599; :

emacs-version "27.1".
Perhaps already fixed.

Message #10 received at 46052 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 46052 <at> debbugs.gnu.org
Subject: Re: bug#46052: Colons fooling GNUmakefile mode
Date: Sat, 23 Jan 2021 14:48:22 +0100

積丹尼 Dan Jacobson <jidanni <at> jidanni.org> writes:

> Perhaps already fixed.

AFAICT this is still reproducible in master (c83590b).

Out of curiosity, I took a look at make-mode.el, thinking it might just
be a matter of adding a [^\t] in a regexp somewhere after a ^ anchor,
but I'm not used to debugging font-lock setups and I don't really know
which occurrence of makefile-targets is responsible for this spurious
fontification (maybe the one paired with makefile-match-dependency,
which relies on makefile-dependency-regex?).

It sure would be nice if make-mode could check whether a line starts
with a tab before slapping the makefile-targets face on it.

(Supporting .RECIPEPREFIX would also be neat I guess, though the fact
that this variable can be set multiple times in a single makefile will
probably pose an interesting challenge.)

Message #13 received at 46052 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 46052 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#46052: Colons fooling GNUmakefile mode
Date: Sat, 23 Jan 2021 16:00:06 +0200

> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Date: Sat, 23 Jan 2021 14:48:22 +0100
> Cc: 46052 <at> debbugs.gnu.org
> 
> It sure would be nice if make-mode could check whether a line starts
> with a tab before slapping the makefile-targets face on it.

I'm not sure a target line cannot possibly start with a TAB.

Message #16 received at 46052 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46052 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#46052: Colons fooling GNUmakefile mode
Date: Sat, 23 Jan 2021 15:58:58 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> I'm not sure a target line cannot possibly start with a TAB.

I'll admit to not being an expert in makefile syntax; I do find this
entry in (info "(make) Error Messages") encouraging though:

> 'recipe commences before first target. Stop.'
> 'missing rule before recipe. Stop.'
>      This means the first thing in the makefile seems to be part of a
>      recipe: it begins with a recipe prefix character and doesn't appear
>      to be a legal 'make' directive (such as a variable assignment).
>      Recipes must always be associated with a target.

While that phrasing doesn't rule out subsequent targets from starting
with a TAB, empirically that seems to be the case:

#+begin_src makefile
foo:
	echo foo

	bar:
	echo bar
#+end_src

$ make
echo foo
foo
bar:
make: bar:: No such file or directory
make: *** [makefile:3: foo] Error 127

#+begin_src makefile
foo:
	echo foo

QUUX = CORGE

	bar:
	echo bar
#+end_src

$ make
makefile:6: *** recipe commences before first target.  Stop.

Message #19 received at 46052 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 46052 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#46052: Colons fooling GNUmakefile mode
Date: Sat, 23 Jan 2021 19:23:40 +0200

> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Cc: jidanni <at> jidanni.org,  46052 <at> debbugs.gnu.org
> Date: Sat, 23 Jan 2021 15:58:58 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I'm not sure a target line cannot possibly start with a TAB.
> 
> I'll admit to not being an expert in makefile syntax; I do find this
> entry in (info "(make) Error Messages") encouraging though:
> 
> > 'recipe commences before first target. Stop.'
> > 'missing rule before recipe. Stop.'
> >      This means the first thing in the makefile seems to be part of a
> >      recipe: it begins with a recipe prefix character and doesn't appear
> >      to be a legal 'make' directive (such as a variable assignment).
> >      Recipes must always be associated with a target.
> 
> While that phrasing doesn't rule out subsequent targets from starting
> with a TAB, empirically that seems to be the case:

I didn't say a _rule_ can start with a TAB, I said a rule's _line_
could start with a TAB.  For example (indentation added for
readability):

  foo \
	  bar: baz

Message #22 received at 46052 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46052 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#46052: Colons fooling GNUmakefile mode
Date: Sat, 23 Jan 2021 18:59:48 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> I didn't say a _rule_ can start with a TAB, I said a rule's _line_
> could start with a TAB.  For example (indentation added for
> readability):
>
>   foo \
> 	  bar: baz

Thanks!  I suspected there could be cases I hadn't thought of; sorry to
have misunderstood your point.

FWIW, right now make-mode seems to fail to fontify your example
correctly, ironically: I'm not seeing any face applied to the target
("foo \\\n\tbar").

Message #25 received at 46052 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 46052 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#46052: Colons fooling GNUmakefile mode
Date: Sat, 23 Jan 2021 20:26:10 +0200

> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Cc: jidanni <at> jidanni.org,  46052 <at> debbugs.gnu.org
> Date: Sat, 23 Jan 2021 18:59:48 +0100
> 
> >   foo \
> > 	  bar: baz
> 
> Thanks!  I suspected there could be cases I hadn't thought of; sorry to
> have misunderstood your point.
> 
> FWIW, right now make-mode seems to fail to fontify your example
> correctly, ironically: I'm not seeing any face applied to the target
> ("foo \\\n\tbar").

I wrote that to prevent people from installing a too-simplistic
solution.  I had no idea whether this is correctly supported
currently.

Message #34 received at 46052-done <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Caliph Nomble <calnomble <at> protonmail.com>
Cc: 46052-done <at> debbugs.gnu.org
Subject: Re: isc-dhcp patch-shebang fails when cross-compiling
Date: Mon, 27 Sep 2021 12:35:55 +0200

[Message part 1 (text/plain, inline)]

Caliph Nomble schreef op za 23-01-2021 om 17:40 [+0000]:
> Hi,
> 
> When cross-compiling isc-dhcp (in this case x86-64 to aarch64), patch-shebang
> patches in bash-minimal compiled for x86_64 for the scripts
> libexec/dhclient-script and libexec/.dhclient-script-real. This pretty much
> prevents dhclient from working, requiring manual network configuration.

The current definition of isc-dhcp on master has some modifications to
patch in a cross-compiled bash-minimal instead, so I'm closing the bug report.
If you still notice an issue, feel free to reopen.

Greetings,
Maxime.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.