all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#14503: 24.3.50; MSYS out-of-tree build fails
@ 2013-05-29 13:49 Richard Copley
  2013-05-29 17:12 ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Richard Copley @ 2013-05-29 13:49 UTC (permalink / raw)
  To: 14503

Building Emacs on Windows according to nt/INSTALL.MSYS,
outside the source tree as recommended, "make -k bootstrap"
fails while processing {build_dir}/lib/Makefile, with the errors:

make[2]: Entering directory `/c/emacs/build/lib'
make[2]: *** No rule to make target `alloca.in.h', needed by `alloca.h'.
make[2]: *** No rule to make target `errno.in.h', needed by `errno.h'.
make[2]: *** No rule to make target `execinfo.in.h', needed by `execinfo.h'.
make[2]: *** No rule to make target `getopt.in.h', needed by `getopt.h'.

Note that the prerequisites are at {trunk}/lib/alloca.in.h, etc.
All seems to work fine if I build inside the source tree.

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-05-29 on 57172UHB
Bzr revision: 112768 rgm@gnu.org-20130529071809-s1x95w8thdhvjdc1
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix c:/emacs/emacs-112768 CPPFLAGS='-I G:/usr/include
 -I C:/GnuWin32/include' LDFLAGS='-L G:/usr/lib -L C:/GnuWin32/lib''

Important settings:
  value of $LANG: ENG
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  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:
M-x r - e - b <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort nadvice gnus-util mail-extr emacsbug message format-spec
rfc822 mml easymenu 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 time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns
disp-table w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment lisp-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 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 w32notify w32 multi-tty emacs)





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#14503: 24.3.50; MSYS out-of-tree build fails
  2013-05-29 13:49 bug#14503: 24.3.50; MSYS out-of-tree build fails Richard Copley
@ 2013-05-29 17:12 ` Eli Zaretskii
  2013-05-29 23:48   ` Richard Copley
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2013-05-29 17:12 UTC (permalink / raw)
  To: Richard Copley; +Cc: 14503

> Date: Wed, 29 May 2013 14:49:49 +0100
> From: Richard Copley <rcopley@gmail.com>
> 
> Building Emacs on Windows according to nt/INSTALL.MSYS,
> outside the source tree as recommended, "make -k bootstrap"
> fails while processing {build_dir}/lib/Makefile, with the errors:
> 
> make[2]: Entering directory `/c/emacs/build/lib'
> make[2]: *** No rule to make target `alloca.in.h', needed by `alloca.h'.
> make[2]: *** No rule to make target `errno.in.h', needed by `errno.h'.
> make[2]: *** No rule to make target `execinfo.in.h', needed by `execinfo.h'.
> make[2]: *** No rule to make target `getopt.in.h', needed by `getopt.h'.

Looks like "make bootstrap" is currently broken on Windows when you do
that outside of the source tree.  The problem is tricky, I will fix it
when I have time.  (Btw, the problem I saw does not manifest itself by
the above error messages, it fails in a different way.)

Anyway, you don't need "make bootstrap" on the first build with the
MSYS method.  In fact, you shouldn't need "make bootstrap" at all,
unless there are deep changes in Lisp that break a normal "make"
build.  And, contrary to what you say, there's no recommendation to
bootstrap in INSTALL.MSYS, it says to use just "make".

I just tried a build with "make" outside of the source tree, and I
didn't have the above problems.  (There's a VPATH line in lib/Makefile
that points to the source directory and allows Make to find the
prerequisites.)





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#14503: 24.3.50; MSYS out-of-tree build fails
  2013-05-29 17:12 ` Eli Zaretskii
@ 2013-05-29 23:48   ` Richard Copley
  2013-06-02 17:02     ` Richard Copley
  0 siblings, 1 reply; 11+ messages in thread
From: Richard Copley @ 2013-05-29 23:48 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 14503

On 29 May 2013 18:12, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 29 May 2013 14:49:49 +0100
>> From: Richard Copley <rcopley@gmail.com>
>>
>> Building Emacs on Windows according to nt/INSTALL.MSYS,
>> outside the source tree as recommended, "make -k bootstrap"
>> fails while processing {build_dir}/lib/Makefile, with the errors:
>>
>> make[2]: Entering directory `/c/emacs/build/lib'
>> make[2]: *** No rule to make target `alloca.in.h', needed by `alloca.h'.
>> make[2]: *** No rule to make target `errno.in.h', needed by `errno.h'.
>> make[2]: *** No rule to make target `execinfo.in.h', needed by `execinfo.h'.
>> make[2]: *** No rule to make target `getopt.in.h', needed by `getopt.h'.
>
> Looks like "make bootstrap" is currently broken on Windows when you do
> that outside of the source tree.  The problem is tricky, I will fix it
> when I have time.  (Btw, the problem I saw does not manifest itself by
> the above error messages, it fails in a different way.)
>
> Anyway, you don't need "make bootstrap" on the first build with the
> MSYS method.  In fact, you shouldn't need "make bootstrap" at all,
> unless there are deep changes in Lisp that break a normal "make"
> build.  And, contrary to what you say, there's no recommendation to
> bootstrap in INSTALL.MSYS, it says to use just "make".
>
> I just tried a build with "make" outside of the source tree, and I
> didn't have the above problems.  (There's a VPATH line in lib/Makefile
> that points to the source directory and allows Make to find the
> prerequisites.)

Thanks. I tried that too after reading your reply and got the same
errors again. Possibly there's an issue with VPATH support in the
default MSYS Make. In any case, I don't get this problem with the
pre-release version of Make mentioned in INSTALL.MSYS.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#14503: 24.3.50; MSYS out-of-tree build fails
  2013-05-29 23:48   ` Richard Copley
@ 2013-06-02 17:02     ` Richard Copley
  2013-06-02 17:23       ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Richard Copley @ 2013-06-02 17:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 14503

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

On 30 May 2013 00:48, Richard Copley <rcopley@gmail.com> wrote:

> On 29 May 2013 18:12, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Wed, 29 May 2013 14:49:49 +0100
> >> From: Richard Copley <rcopley@gmail.com>
> >>
> >> Building Emacs on Windows according to nt/INSTALL.MSYS,
> >> outside the source tree as recommended, "make -k bootstrap"
> >> fails while processing {build_dir}/lib/Makefile, with the errors:
> >>
> >> make[2]: Entering directory `/c/emacs/build/lib'
> >> make[2]: *** No rule to make target `alloca.in.h', needed by `alloca.h'.
> >> make[2]: *** No rule to make target `errno.in.h', needed by `errno.h'.
> >> make[2]: *** No rule to make target `execinfo.in.h', needed by
> `execinfo.h'.
> >> make[2]: *** No rule to make target `getopt.in.h', needed by `getopt.h'.
> >
> > Looks like "make bootstrap" is currently broken on Windows when you do
> > that outside of the source tree.  The problem is tricky, I will fix it
> > when I have time.  (Btw, the problem I saw does not manifest itself by
> > the above error messages, it fails in a different way.)
> >
> > Anyway, you don't need "make bootstrap" on the first build with the
> > MSYS method.  In fact, you shouldn't need "make bootstrap" at all,
> > unless there are deep changes in Lisp that break a normal "make"
> > build.  And, contrary to what you say, there's no recommendation to
> > bootstrap in INSTALL.MSYS, it says to use just "make".
> >
> > I just tried a build with "make" outside of the source tree, and I
> > didn't have the above problems.  (There's a VPATH line in lib/Makefile
> > that points to the source directory and allows Make to find the
> > prerequisites.)
>
> Thanks. I tried that too after reading your reply and got the same
> errors again. Possibly there's an issue with VPATH support in the
> default MSYS Make. In any case, I don't get this problem with the
> pre-release version of Make mentioned in INSTALL.MSYS.
>

... but the out-of-tree build is still broken (even with the pre-release
make, and without bootstrap).

The failures are:

Compiling g:/emacs/trunk/lisp/calc/calc-aent.el

In toplevel form:
../../trunk/lisp/calc/calc-aent.el:29:1:Error: Cannot open load file:
calc-loaddefs.el
Makefile:247: recipe for target `calc/calc-aent.elc' failed
make[2]: *** [calc/calc-aent.elc] Error 1
make[2]: Leaving directory `/g/emacs/build/lisp'

Compiling g:/emacs/trunk/lisp/eshell/em-alias.el

In toplevel form:
../../trunk/lisp/eshell/em-alias.el:93:1:Error: Cannot open load file:
esh-groups
Makefile:247: recipe for target `eshell/em-alias.elc' failed
make[2]: *** [eshell/em-alias.elc] Error 1
make[2]: Leaving directory `/g/emacs/build/lisp'

Compiling g:/emacs/trunk/lisp/org/ob-calc.el

In toplevel form:
../../trunk/lisp/org/ob-calc.el:30:1:Error: Cannot open load file:
calc-loaddefs.el
Makefile:247: recipe for target `org/ob-calc.elc' failed
make[2]: *** [org/ob-calc.elc] Error 1
make[2]: Leaving directory `/g/emacs/build/lisp'

[-- Attachment #2: Type: text/html, Size: 3994 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#14503: 24.3.50; MSYS out-of-tree build fails
  2013-06-02 17:02     ` Richard Copley
@ 2013-06-02 17:23       ` Eli Zaretskii
  2013-06-02 17:58         ` Richard Copley
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2013-06-02 17:23 UTC (permalink / raw)
  To: Richard Copley; +Cc: 14503

> Date: Sun, 2 Jun 2013 18:02:07 +0100
> From: Richard Copley <rcopley@gmail.com>
> Cc: 14503@debbugs.gnu.org
> 
> ... but the out-of-tree build is still broken (even with the pre-release
> make, and without bootstrap).

Not here, sorry.

It sounds like the files it cannot find are all generated by saving
the autoloads of certain Lisp packages.  Did you perhaps inadvertently
deleted those files?  If so, does "make autoloads" in the Lisp
directory solve the problem?





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#14503: 24.3.50; MSYS out-of-tree build fails
  2013-06-02 17:23       ` Eli Zaretskii
@ 2013-06-02 17:58         ` Richard Copley
  2013-06-02 18:11           ` Richard Copley
  2013-06-02 18:16           ` Eli Zaretskii
  0 siblings, 2 replies; 11+ messages in thread
From: Richard Copley @ 2013-06-02 17:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 14503

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

[Yet again, sorry for dropping the bug from the CC.]
On 2 June 2013 18:23, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 2 Jun 2013 18:02:07 +0100
> > From: Richard Copley <rcopley@gmail.com>
> > Cc: 14503@debbugs.gnu.org
> >
> > ... but the out-of-tree build is still broken (even with the pre-release
> > make, and without bootstrap).
>
> Not here, sorry.
>
> It sounds like the files it cannot find are all generated by saving
> the autoloads of certain Lisp packages.  Did you perhaps inadvertently
> deleted those files?


No. I did this:

bzr clean-tree --unknown --ignored --detritus --verbose --force
bzr revert --no-backup
bzr pull --overwrite
bzr update

before running autogen, configure and make in MSYS.


>  If so, does "make autoloads" in the Lisp
> directory solve the problem?
>

Possibly, I will check. But make should still make, right?

[-- Attachment #2: Type: text/html, Size: 1636 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#14503: 24.3.50; MSYS out-of-tree build fails
  2013-06-02 17:58         ` Richard Copley
@ 2013-06-02 18:11           ` Richard Copley
  2013-06-02 18:16           ` Eli Zaretskii
  1 sibling, 0 replies; 11+ messages in thread
From: Richard Copley @ 2013-06-02 18:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 14503


[-- Attachment #1.1: Type: text/plain, Size: 512 bytes --]

On 2 June 2013 18:58, Richard Copley <rcopley@gmail.com> wrote:

> On 2 June 2013 18:23, Eli Zaretskii <eliz@gnu.org> wrote:
>  If so, does "make autoloads" in the Lisp
>
>> directory solve the problem?
>>
> Possibly, I will check. But make should still make, right?
>

"make autoloads" in the lisp directory succeeds, but there
are errors from some of the commands (this is perhaps
nearer the root cause of the error). Subsequent "make"
still fails as before. I've attached the output of
"make autoloads 2>&1".

[-- Attachment #1.2: Type: text/html, Size: 1314 bytes --]

[-- Attachment #2: make-autoloads.log --]
[-- Type: application/octet-stream, Size: 3191 bytes --]

EMACSLOADPATH=g:/emacs/trunk/lisp LC_ALL=C /g/emacs/build/src/emacs -batch --no-site-file --no-site-lisp -l autoload \
   --eval "(setq generate-autoload-cookie \";;;###cal-autoload\")" \
   --eval "(setq generated-autoload-file (unmsys--file-name \"g:/emacs/trunk/lisp/calendar/cal-loaddefs.el\"))" \
   --eval "(setq make-backup-files nil)" \
   -f batch-update-autoloads g:/emacs/trunk/lisp/calendar
Invalid escape character syntax
EMACSLOADPATH=g:/emacs/trunk/lisp LC_ALL=C /g/emacs/build/src/emacs -batch --no-site-file --no-site-lisp -l autoload \
   --eval "(setq generate-autoload-cookie \";;;###diary-autoload\")" \
   --eval "(setq generated-autoload-file (unmsys--file-name \"g:/emacs/trunk/lisp/calendar/diary-loaddefs.el\"))" \
   --eval "(setq make-backup-files nil)" \
   -f batch-update-autoloads g:/emacs/trunk/lisp/calendar
Invalid escape character syntax
EMACSLOADPATH=g:/emacs/trunk/lisp LC_ALL=C /g/emacs/build/src/emacs -batch --no-site-file --no-site-lisp -l autoload \
   --eval "(setq generate-autoload-cookie \";;;###holiday-autoload\")" \
   --eval "(setq generated-autoload-file (unmsys--file-name \"g:/emacs/trunk/lisp/calendar/hol-loaddefs.el\"))" \
   --eval "(setq make-backup-files nil)" \
   -f batch-update-autoloads g:/emacs/trunk/lisp/calendar
Invalid escape character syntax
EMACSLOADPATH=g:/emacs/trunk/lisp LC_ALL=C /g/emacs/build/src/emacs -batch --no-site-file --no-site-lisp -l autoload \
   --eval "(setq generate-autoload-cookie \";;;###mh-autoload\")" \
   --eval "(setq generated-autoload-file (unmsys--file-name \"g:/emacs/trunk/lisp/mh-e/mh-loaddefs.el\"))" \
   --eval "(setq make-backup-files nil)" \
   -f batch-update-autoloads g:/emacs/trunk/lisp/mh-e
Invalid escape character syntax
EMACSLOADPATH=g:/emacs/trunk/lisp LC_ALL=C /g/emacs/build/src/emacs -batch --no-site-file --no-site-lisp -l autoload \
   --eval "(setq generate-autoload-cookie \";;;###tramp-autoload\")" \
   --eval "(setq generated-autoload-file (unmsys--file-name \"g:/emacs/trunk/lisp/net/tramp-loaddefs.el\"))" \
   --eval "(setq make-backup-files nil)" \
   -f batch-update-autoloads g:/emacs/trunk/lisp/net
Invalid escape character syntax
cd g:/emacs/trunk/lisp && chmod +w ps-print.el  emulation/tpu-edt.el  emacs-lisp/cl-loaddefs.el  mail/rmail.el  dired.el  ibuffer.el  htmlfontify.el  emacs-lisp/eieio.el
cd g:/emacs/trunk/lisp; subdirs=`find . -type d -print`;  for file in $subdirs; do  case $file in */.* | */.*/* | */=* | */obsolete | */term ) ;;  *) wins="$wins $file" ;;  esac;  done; \
echo Directories: $wins; \
EMACSLOADPATH=g:/emacs/trunk/lisp LC_ALL=C /g/emacs/build/src/emacs -batch --no-site-file --no-site-lisp -l autoload --eval '(setq generated-autoload-file (unmsys--file-name "g:/emacs/trunk/lisp/loaddefs.el"))' -f batch-update-autoloads $wins
Directories: . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine ./cedet/semantic/decorate ./cedet/semantic/symref ./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emulation ./erc ./eshell ./gnus ./international ./language ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./vc
Invalid escape character syntax

^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#14503: 24.3.50; MSYS out-of-tree build fails
  2013-06-02 17:58         ` Richard Copley
  2013-06-02 18:11           ` Richard Copley
@ 2013-06-02 18:16           ` Eli Zaretskii
       [not found]             ` <CAPM58og7pxE2xW3pc+4WvHoBW_9+GDEbot16pNUPbN949b4_CA@mail.gmail.com>
  1 sibling, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2013-06-02 18:16 UTC (permalink / raw)
  To: Richard Copley; +Cc: 14503

> Date: Sun, 2 Jun 2013 18:58:23 +0100
> From: Richard Copley <rcopley@gmail.com>
> Cc: 14503@debbugs.gnu.org
> 
> bzr clean-tree --unknown --ignored --detritus --verbose --force
> bzr revert --no-backup
> bzr pull --overwrite
> bzr update
> 
> before running autogen, configure and make in MSYS.

It's possible that the above commands don't produce a clean branch.  I
suggest to do a "bzr branch" and then compare the pristine branch with
this one.

> >  If so, does "make autoloads" in the Lisp
> > directory solve the problem?
> >
> 
> Possibly, I will check. But make should still make, right?

The "all" target doesn't seem to invoke anything that recreates those
files.  Whether that is a or isn't a bug is another matter, but it
surely isn't Windows specific.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#14503: 24.3.50; MSYS out-of-tree build fails
       [not found]             ` <CAPM58og7pxE2xW3pc+4WvHoBW_9+GDEbot16pNUPbN949b4_CA@mail.gmail.com>
@ 2013-06-02 19:28               ` Eli Zaretskii
  2013-06-02 20:27                 ` Richard Copley
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2013-06-02 19:28 UTC (permalink / raw)
  To: Richard Copley; +Cc: 14503

> Date: Sun, 2 Jun 2013 19:48:32 +0100
> From: Richard Copley <rcopley@gmail.com>
> 
> > > >  If so, does "make autoloads" in the Lisp
> > > > directory solve the problem?
> > > >
> > >
> > > Possibly, I will check. But make should still make, right?
> >
> > The "all" target doesn't seem to invoke anything that recreates those
> > files.
> 
> 
> They do get created by "make all" when run inside the tree.

I think the problem is here:

  EMACSLOADPATH=g:/emacs/trunk/lisp LC_ALL=C /g/emacs/build/src/emacs -batch --no-site-file --no-site-lisp -l autoload \
     --eval "(setq generate-autoload-cookie \";;;###cal-autoload\")" \
     --eval "(setq generated-autoload-file (unmsys--file-name \"g:/emacs/trunk/lisp/calendar/cal-loaddefs.el\"))" \
                                                               ^^^^

How come you get here "d:/foo/bar" style of file names, and not MSYS's
usual "/d/foo/bar"?  Did you per chance invoke the configure script as
"g:/emacs/trunk/nt/msysconfig ..."?  If so, try "/g/emacs/..."
instead.

I think what happens in the above command is that MSYS converts

  g:/emacs/trunk/lisp/calendar/cal-loaddefs.el

into

  g;\emacs\trunk\lisp\calendar\cal-loaddefs.el

(note the semi-colon and the backslashes), because it thinks this is a
colon-separated path.  That's why Emacs complains about invalid escape
sequences.  Can you add a 'message' to unmsys--file-name to see what
kind of argument it is called with?





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#14503: 24.3.50; MSYS out-of-tree build fails
  2013-06-02 19:28               ` Eli Zaretskii
@ 2013-06-02 20:27                 ` Richard Copley
  2013-06-03 16:59                   ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Richard Copley @ 2013-06-02 20:27 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 14503

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

On 2 June 2013 20:28, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 2 Jun 2013 19:48:32 +0100
> > From: Richard Copley <rcopley@gmail.com>
> >
> > > > >  If so, does "make autoloads" in the Lisp
> > > > > directory solve the problem?
> > > > >
> > > >
> > > > Possibly, I will check. But make should still make, right?
> > >
> > > The "all" target doesn't seem to invoke anything that recreates those
> > > files.
> >
> >
> > They do get created by "make all" when run inside the tree.
>
> I think the problem is here:
>
>   EMACSLOADPATH=g:/emacs/trunk/lisp LC_ALL=C /g/emacs/build/src/emacs
> -batch --no-site-file --no-site-lisp -l autoload \
>      --eval "(setq generate-autoload-cookie \";;;###cal-autoload\")" \
>      --eval "(setq generated-autoload-file (unmsys--file-name
> \"g:/emacs/trunk/lisp/calendar/cal-loaddefs.el\"))" \
>                                                                ^^^^
>
> How come you get here "d:/foo/bar" style of file names, and not MSYS's
> usual "/d/foo/bar"?  Did you per chance invoke the configure script as
> "g:/emacs/trunk/nt/msysconfig ..."?  If so, try "/g/emacs/..."
> instead.
>

Yes, exactly that. My mistake. Sorry for taking up your time. Thank you.


> I think what happens in the above command is that MSYS converts
>
>   g:/emacs/trunk/lisp/calendar/cal-loaddefs.el
>
> into
>
>   g;\emacs\trunk\lisp\calendar\cal-loaddefs.el
>
> (note the semi-colon and the backslashes), because it thinks this is a
> colon-separated path.  That's why Emacs complains about invalid escape
> sequences.  Can you add a 'message' to unmsys--file-name to see what
> kind of argument it is called with?
>

Seems the crash occurred before unmsys--file-name was actually called,
because the message never got printed.

[-- Attachment #2: Type: text/html, Size: 2681 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#14503: 24.3.50; MSYS out-of-tree build fails
  2013-06-02 20:27                 ` Richard Copley
@ 2013-06-03 16:59                   ` Eli Zaretskii
  0 siblings, 0 replies; 11+ messages in thread
From: Eli Zaretskii @ 2013-06-03 16:59 UTC (permalink / raw)
  To: Richard Copley; +Cc: 14503

> Date: Sun, 2 Jun 2013 21:27:03 +0100
> From: Richard Copley <rcopley@gmail.com>
> Cc: 14503@debbugs.gnu.org
> 
> > I think the problem is here:
> >
> >   EMACSLOADPATH=g:/emacs/trunk/lisp LC_ALL=C /g/emacs/build/src/emacs
> > -batch --no-site-file --no-site-lisp -l autoload \
> >      --eval "(setq generate-autoload-cookie \";;;###cal-autoload\")" \
> >      --eval "(setq generated-autoload-file (unmsys--file-name
> > \"g:/emacs/trunk/lisp/calendar/cal-loaddefs.el\"))" \
> >                                                                ^^^^
> >
> > How come you get here "d:/foo/bar" style of file names, and not MSYS's
> > usual "/d/foo/bar"?  Did you per chance invoke the configure script as
> > "g:/emacs/trunk/nt/msysconfig ..."?  If so, try "/g/emacs/..."
> > instead.
> >
> 
> Yes, exactly that. My mistake. Sorry for taking up your time. Thank you.

I updated the instructions advising against using Windows style file
names.





^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2013-06-03 16:59 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-05-29 13:49 bug#14503: 24.3.50; MSYS out-of-tree build fails Richard Copley
2013-05-29 17:12 ` Eli Zaretskii
2013-05-29 23:48   ` Richard Copley
2013-06-02 17:02     ` Richard Copley
2013-06-02 17:23       ` Eli Zaretskii
2013-06-02 17:58         ` Richard Copley
2013-06-02 18:11           ` Richard Copley
2013-06-02 18:16           ` Eli Zaretskii
     [not found]             ` <CAPM58og7pxE2xW3pc+4WvHoBW_9+GDEbot16pNUPbN949b4_CA@mail.gmail.com>
2013-06-02 19:28               ` Eli Zaretskii
2013-06-02 20:27                 ` Richard Copley
2013-06-03 16:59                   ` Eli Zaretskii

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.