* bug#14411: 24.3.50; compile.el: Better file search for parallel builds
@ 2013-05-16 19:09 David Engster
2013-05-16 19:19 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: David Engster @ 2013-05-16 19:09 UTC (permalink / raw)
To: 14411
[-- 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#14411: 24.3.50; compile.el: Better file search for parallel builds
2013-05-16 19:09 bug#14411: 24.3.50; compile.el: Better file search for parallel builds David Engster
@ 2013-05-16 19:19 ` Eli Zaretskii
2020-09-18 14:35 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2013-05-16 19:19 UTC (permalink / raw)
To: David Engster; +Cc: 14411
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#14411: 24.3.50; compile.el: Better file search for parallel builds
2013-05-16 19:19 ` Eli Zaretskii
@ 2020-09-18 14:35 ` Lars Ingebrigtsen
2020-09-18 15:36 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-18 14:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14411, David Engster
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#14411: 24.3.50; compile.el: Better file search for parallel builds
2020-09-18 14:35 ` Lars Ingebrigtsen
@ 2020-09-18 15:36 ` Eli Zaretskii
2020-09-18 15:39 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2020-09-18 15:36 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 14411, deng
> 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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#14411: 24.3.50; compile.el: Better file search for parallel builds
2020-09-18 15:36 ` Eli Zaretskii
@ 2020-09-18 15:39 ` Lars Ingebrigtsen
2020-10-15 14:49 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-18 15:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14411, deng
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#14411: 24.3.50; compile.el: Better file search for parallel builds
2020-09-18 15:39 ` Lars Ingebrigtsen
@ 2020-10-15 14:49 ` Lars Ingebrigtsen
0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-15 14:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14411, deng
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-10-15 14:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-16 19:09 bug#14411: 24.3.50; compile.el: Better file search for parallel builds David Engster
2013-05-16 19:19 ` Eli Zaretskii
2020-09-18 14:35 ` Lars Ingebrigtsen
2020-09-18 15:36 ` Eli Zaretskii
2020-09-18 15:39 ` Lars Ingebrigtsen
2020-10-15 14:49 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).