bug#14411: 24.3.50; compile.el: Better file search for parallel builds

bug#14411: 24.3.50; compile.el: Better file search for parallel builds

[David Engster]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: compile-parallel-patch.diff --]
[-- Type: text/x-diff, Size: 2276 bytes --]

=== 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.

bug#14411: 24.3.50; compile.el: Better file search for parallel builds

[Eli Zaretskii]

> From: David Engster <deng@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.

bug#14411: 24.3.50; compile.el: Better file search for parallel builds

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#14411: 24.3.50; compile.el: Better file search for parallel builds

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: David Engster <deng@randomsample.de>,  14411@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?

bug#14411: 24.3.50; compile.el: Better file search for parallel builds

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#14411: 24.3.50; compile.el: Better file search for parallel builds

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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