GNU bug report logs - #42411
Bug with M-x compile

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: psmith <at> gnu.org
Cc: 42411 <at> debbugs.gnu.org
Subject: Re: bug#42411: Bug with M-x compile
Date: Fri, 31 Jul 2020 21:42:01 +0300

> From: Paul Smith <psmith <at> gnu.org>
> Cc: 42411 <at> debbugs.gnu.org
> Date: Fri, 31 Jul 2020 14:20:38 -0400
> 
> It's definitely true that technically, it is possible to have targets
> that are indented by TABs.  A line indented by a TAB is only considered
> part of a recipe if it appears in the "recipe context", which means
> somewhere that a recipe is legal in the syntax.
> 
> If it's not legal for a recipe command to appear there then TABs are
> treated like any other whitespace.
> 
> In practice, I think it's highly unlikely that anyone would
> intentionally use TABs to indent targets because it's so fragile: any
> reordering of the makefile or adding new lines could cause that
> makefile to break.
> 
> So, as a simplifying assumption it makes sense to me to ignore any line
> starting with TAB when trying to detect targets.
> 
> Of course, as Eli points out there are certainly a large number of
> potential targets which cannot be determined using this type of simple
> investigation.  The most obvious are targets that match patterns.
> 
> However I'll say two things about this:
> 
> First, I think it's unlikely that users would really want to see all
> the potential matches of targets when doing completion.  It's most
> likely that they are interested in the "top level" intended command
> line goals rather than every possible object, source, etc. file that
> make considers a target due to pattern or suffix rules.
> 
> Second, I don't think there's currently any good way to list those
> targets anyway.  Just using --print-database by itself won't do it.
>  Using the -n option will help, but many makefiles are not carefully
> written to ensure that -n is really idempotent, and make -n could
> delete files or similar operations.  And of course this still only
> finds the targets that are available "by default"; providing a target
> on the command line could cause more pattern rules to generate more
> targets that the "default" goal target doesn't.
> 
> I hope that helps but if I completely missed the point please feel free
> to redirect me!

Thanks for the feedback.

So you think the current regexp is trying to match too much, and the
proposed change is TRT and we should make it unconditionally?

Previous Next

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