GNU bug report logs - #14411
24.3.50; compile.el: Better file search for parallel builds

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 14411 in the body.
You can then email your comments to 14411 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: David Engster <deng <at> randomsample.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; compile.el: Better file search for parallel builds
Date: Thu, 16 May 2013 21:09:38 +0200

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

When doing parallel builds using GNU Make, jumping to the location of a
warning/error from the compilation buffer often does not work. This is
because GNU Make enters different directories at the same time, and the
resulting output is intermixed. The attached patch fixes this by looking
at all directories which were entered up to the point of the
warning/error, instead of just taking the directly preceding one. I'm
aware that this is not a perfect solution, since those directories might
contain files with identical names, in which case Emacs might show the
wrong one, but IMO it's still an improvement over the current
situation. This feature can also be disabled through a new variable.

-David

[compile-parallel-patch.diff (text/x-diff, inline)]

=== modified file 'lisp/progmodes/compile.el'
--- lisp/progmodes/compile.el	2013-04-24 13:50:22 +0000
+++ lisp/progmodes/compile.el	2013-05-16 18:49:35 +0000
@@ -611,6 +611,18 @@
 			 (string :tag "Directory")))
   :group 'compilation)
 
+(defcustom compilation-search-all-directories t
+  "Whether further upward directories should be used when searching a file.
+When doing a parallel build, several files from different
+directories can be compiled at the same time.  This makes it
+difficult to determine the base directory for a relative file
+name in a compiler error or warning.  If this variable is
+non-nil, instead of just relying on the previous directory change
+in the compilation buffer, all other directories further upwards
+will be used as well."
+  :type 'boolean
+  :group 'compilation)
+
 ;;;###autoload
 (defcustom compile-command (purecopy "make -k ")
   "Last shell command used to do a compilation; default for next compilation.
@@ -2616,6 +2628,25 @@
                           (find-file-noselect name))
               fmts (cdr fmts)))
       (setq dirs (cdr dirs)))
+    ;; If we haven't found it, this might be a parallel build.
+    ;; Search the directories further up the buffer.
+    (when (and (null buffer)
+               compilation-search-all-directories)
+      (with-current-buffer (marker-buffer marker)
+        (save-excursion
+          (goto-char (marker-position marker))
+          (goto-char (compilation--previous-directory (point)))
+          (setq dirs (cdr (or (get-text-property (1- (point)) 'compilation-directory)
+                              (get-text-property (point) 'compilation-directory))))))
+      (while (and dirs (null buffer))
+        (setq thisdir (car dirs)
+              fmts formats)
+        (while (and fmts (null buffer))
+          (setq name (expand-file-name (format (car fmts) filename) thisdir)
+                buffer (and (file-exists-p name)
+                            (find-file-noselect name))
+                fmts (cdr fmts)))
+        (setq dirs (cdr dirs))))
     (while (null buffer)    ;Repeat until the user selects an existing file.
       ;; The file doesn't exist.  Ask the user where to find it.
       (save-excursion            ;This save-excursion is probably not right.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: David Engster <deng <at> randomsample.de>
Cc: 14411 <at> debbugs.gnu.org
Subject: Re: bug#14411: 24.3.50;
	compile.el: Better file search for parallel builds
Date: Thu, 16 May 2013 22:19:48 +0300

> From: David Engster <deng <at> randomsample.de>
> Date: Thu, 16 May 2013 21:09:38 +0200
> 
> When doing parallel builds using GNU Make, jumping to the location of a
> warning/error from the compilation buffer often does not work. This is
> because GNU Make enters different directories at the same time, and the
> resulting output is intermixed. The attached patch fixes this by looking
> at all directories which were entered up to the point of the
> warning/error, instead of just taking the directly preceding one. I'm
> aware that this is not a perfect solution, since those directories might
> contain files with identical names, in which case Emacs might show the
> wrong one, but IMO it's still an improvement over the current
> situation. This feature can also be disabled through a new variable.

I think this problem should be fixed in GNU Make.  And, lo and behold,
the next release of GNU Make will have a switch that will prevent the
directories from being mixed.  Perhaps it would be better to teach
compile.el to detect support for that switch (-O or --output-sync) and
use it if available when -j is also used, than to kludge around the
current behavior.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14411 <at> debbugs.gnu.org, David Engster <deng <at> randomsample.de>
Subject: Re: bug#14411: 24.3.50; compile.el: Better file search for parallel
 builds
Date: Fri, 18 Sep 2020 16:35:50 +0200

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

> I think this problem should be fixed in GNU Make.  And, lo and behold,
> the next release of GNU Make will have a switch that will prevent the
> directories from being mixed.  Perhaps it would be better to teach
> compile.el to detect support for that switch (-O or --output-sync) and
> use it if available when -j is also used, than to kludge around the
> current behavior.

Well, we could just say that it's up to people to type -Oj instead of
just -j...

On the other hand, David's patch seems to fix this stuff automatically,
so my preference would be to just drop the defcustom and do the search,
anyway -- it's only done if we can't find the file name otherwise, so it
should only help, and never (?) hurt?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 14411 <at> debbugs.gnu.org, deng <at> randomsample.de
Subject: Re: bug#14411: 24.3.50; compile.el: Better file search for parallel
 builds
Date: Fri, 18 Sep 2020 18:36:04 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: David Engster <deng <at> randomsample.de>,  14411 <at> debbugs.gnu.org
> Date: Fri, 18 Sep 2020 16:35:50 +0200
> 
> On the other hand, David's patch seems to fix this stuff automatically,
> so my preference would be to just drop the defcustom and do the search,
> anyway -- it's only done if we can't find the file name otherwise, so it
> should only help, and never (?) hurt?

I don't mind installing the feature.  But can we just make sure it is
still effective, with modern Make and our current Makefiles?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14411 <at> debbugs.gnu.org, deng <at> randomsample.de
Subject: Re: bug#14411: 24.3.50; compile.el: Better file search for parallel
 builds
Date: Fri, 18 Sep 2020 17:39:24 +0200

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

>> On the other hand, David's patch seems to fix this stuff automatically,
>> so my preference would be to just drop the defcustom and do the search,
>> anyway -- it's only done if we can't find the file name otherwise, so it
>> should only help, and never (?) hurt?
>
> I don't mind installing the feature.  But can we just make sure it is
> still effective, with modern Make and our current Makefiles?

Well, this isn't just an issue with Emacs' Makefiles, but any project
that's building under `M-x compile'.

But, true, I have no idea whether modern Make has this issue at all.
The presence of the -O switch seems to imply that it's still an issue.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14411 <at> debbugs.gnu.org, deng <at> randomsample.de
Subject: Re: bug#14411: 24.3.50; compile.el: Better file search for parallel
 builds
Date: Thu, 15 Oct 2020 16:49:39 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

>> I don't mind installing the feature.  But can we just make sure it is
>> still effective, with modern Make and our current Makefiles?
>
> Well, this isn't just an issue with Emacs' Makefiles, but any project
> that's building under `M-x compile'.

I went ahead and installed the change in Emacs 28 -- it shouldn't break
anything (I hope; I've tried a couple of test cases by rearranging the
output in the *compilation* buffer and seeing that it doesn't), and it
should help make this work automatically for those who see this problem.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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