bug#15795: 24.3.50; Compile uses relative filenames, breaks goto next error.

bug#15795: 24.3.50; Compile uses relative filenames, breaks goto next error.

[Jan Djärv]

Hello.

I usually compile Emacs in a separate object directory.  From the source directory
/Users/jhd/src/emacs/current I use something like:

M-x compile <RET> cd /Users/jhd/src/emacs/obj-cur-osx && make <RET>
A warning/error in *compilation* uses relative filenames:

../../current/src/nsfont.m:889:28: warning: 'ATSFontFindFromPostScriptName' is
      deprecated: first deprecated in OS X 10.8 - Use CTFontCreateWithName()
      [-Wdeprecated-declarations]
      ATSFontRef atsFont = ATSFontFindFromPostScriptName

Clicking on the warning/error, or using next-error, prompts me to find the file, it isn't found  automatically.

If I switch to an emacs-24 branch configured exactly the same (same machine, same tools, same program versions, same Emacs used for compilation), it results in compilation output like this:

/Users/jhd/src/emacs/emacs-24/src/nsfont.m:1230:35: warning: 'Fix2X' is
      deprecated: first deprecated in OS X 10.8 [-Wdeprecated-declarations]
    fliptf.c =  font->synthItal ? Fix2X (kATSItalicQDSkew) : 0.0;

i.e. absolute filenames used and next-error finds the file.

So something in the trunk has changed to use relative filenames.  Either that change should be reverted as this is a regression, or compilation-mode should be made smarter.

I see this on GNU/Linux also.

	Jan D.


In GNU Emacs 24.3.50.1 (x86_64-apple-darwin13.0.0, NS apple-appkit-1265.00)
of 2013-11-02 on zeplin
Bzr revision: 114901 dgutov@yandex.ru-20131102051811-f9s9rj8g4fvqkd2h
Windowing system distributor `Apple', version 10.3.1265
Configured using:
`configure --verbose --with-ns CFLAGS=-g3'

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: sv_SE.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Change Log

Minor modes in effect:
  bug-reference-mode: t
  icomplete-mode: t
  desktop-save-mode: t
  delete-selection-mode: t
  display-time-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<escape> x r e p o r t - e m <tab> <return>

Recent messages:
Loading /Users/jhd/lib/elisp/BAK-file.el (source)...done
Loading cc-langs...done
Loading /Users/jhd/lib/elisp/ccsetup.el (source)...done
Loading desktop...done
Loading icomplete...done
Wrote /Users/jhd/src/emacs/current/.emacs.desktop.lock
Desktop: 1 frame, 30 buffers restored.
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
/Users/jhd/.emacs.d/elpa/magit-20130525.2329/.dir-locals hides /Users/jhd/Applications/Emacs.app/Contents/Resources/lisp/gnus/.dir-locals

Features:
(shadow sort gnus-util mail-extr emacsbug message cl-macs gv format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils vc-git vc-dir ewoc vc vc-dispatcher vc-bzr
bug-reference add-log magit-autoloads package icomplete desktop frameset
cus-start cus-load msb delsel advice help-fns cc-langs cl cl-loaddefs
cl-lib cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs time time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process cocoa ns
multi-tty emacs)

bug#15795: 24.3.50; Compile uses relative filenames, breaks goto next error.

[Glenn Morris]

Jan Djärv wrote:

> So something in the trunk has changed to use relative filenames. 

Yes, it's changed.

> compilation-mode should be made smarter.

I think that is what should happen.

bug#15795: 24.3.50; Compile uses relative filenames, breaks goto next error.

[Glenn Morris]

PS try configuring your out-of-tree build using an absolute path to the
srcdir.

bug#15795: 24.3.50; Compile uses relative filenames, breaks goto next error.

[Jan Djärv]

Hello.

4 nov 2013 kl. 09:10 skrev Glenn Morris <rgm@gnu.org>:

> 
> PS try configuring your out-of-tree build using an absolute path to the
> srcdir.

That workaround works.

	Jan D.

bug#15795: 24.3.50; Compile uses relative filenames, breaks goto next error.

[Jan Djärv]

Hello.

2013-11-04 19:34, Jan Djärv skrev:
> Hello.
>
> 4 nov 2013 kl. 09:10 skrev Glenn Morris <rgm@gnu.org>:
>
>>
>> PS try configuring your out-of-tree build using an absolute path to the
>> srcdir.
>
> That workaround works.

After I finally got round to do some debugging, I find that compile-mode does 
directory tracking, but for English only.  After setting up 
compilation-directory-matcher to handle my locale and english, everything 
works as expected.  Closing this bug.

For future reference, one might consider popping up a warning and a pointer to 
compilation-directory-matcher if the file is not found and directory tracking 
did not track a single directory.  Or use a more general regexp (don't know if 
that is possible), or force the C locale, or convice GNU make to add a 
specific switch, much like GNU ls has --dired.

Come to think of it, if doing parallel make where each job goes into separate 
directories, directory tracking will most likely fail, as output from 
different jobs are intermixed.  So directory tracking is not robust.

	Jan D.

bug#15795: 24.3.50; Compile uses relative filenames, breaks goto next error.

[Glenn Morris]

Jan Djärv wrote:

> Come to think of it, if doing parallel make where each job goes into
> separate directories, directory tracking will most likely fail, as
> output from different jobs are intermixed.  So directory tracking is
> not robust.

https://www.gnu.org/software/make/manual/html_node/Parallel-Output.html

bug#15795: 24.3.50; Compile uses relative filenames, breaks goto next error.

[David Engster]

Glenn Morris writes:
> Jan Djärv wrote:
>
>> Come to think of it, if doing parallel make where each job goes into
>> separate directories, directory tracking will most likely fail, as
>> output from different jobs are intermixed.  So directory tracking is
>> not robust.
>
> https://www.gnu.org/software/make/manual/html_node/Parallel-Output.html

See also

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14411

While I'm also using -Orecurse nowadays on systems where I have the
latest GNU Make 4, I still think that at least trying to find the
correct location for older versions of Make wouldn't hurt.

-David