emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#15795: closed (24.3.50; Compile uses relative file


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#15795: closed (24.3.50; Compile uses relative filenames, breaks goto next error.)
Date: Fri, 04 Jul 2014 10:34:02 +0000

Your message dated Fri, 04 Jul 2014 12:33:30 +0200
with message-id <address@hidden>
and subject line Re: bug#15795: 24.3.50; Compile uses relative filenames, 
breaks goto next error.
has caused the debbugs.gnu.org bug report #15795,
regarding 24.3.50; Compile uses relative filenames, breaks goto next error.
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
15795: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15795
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 24.3.50; Compile uses relative filenames, breaks goto next error. Date: Sun, 3 Nov 2013 10:27:52 +0100
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 address@hidden
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)



--- End Message ---
--- Begin Message --- Subject: Re: bug#15795: 24.3.50; Compile uses relative filenames, breaks goto next error. Date: Fri, 04 Jul 2014 12:33:30 +0200 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
Hello.

2013-11-04 19:34, Jan Djärv skrev:
Hello.

4 nov 2013 kl. 09:10 skrev Glenn Morris <address@hidden>:


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.



--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]