GNU bug report logs - #16099
MinGW build failure when srcdir is absolute and has "wrong" format

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16099 in the body.
You can then email your comments to 16099 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 12:13:04 +0000

[Message part 1 (text/plain, inline)]

Building Emacs from trunk r115447, I get several errors and warnings
about undefined functions/macros in the cl- namespace. See build output
attached. For example, byte-compiling "ffap.el" fails with:

In toplevel form:
../../trunk/lisp/ffap.el:108:1:Error: Symbol's function definition is void:
cl-member
Makefile:272: recipe for target `ffap.elc' failed
make[2]: *** [ffap.elc] Error 1

The build runs to completion but the resulting Emacs has problems. For
example, from "runemacs -Q", "M-x ffap RET" fails with:

Symbol's function definition is void: cl-member

There might be a problem with my build environment. I haven't tried
to build Emacs for quite a while.

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-12-10 on 57172UHB
Bzr revision: 115447 dmantipov <at> yandex.ru-20131210033636-vb02ptzqwu00b0bc
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix c:/emacs/emacs-115447
 --enable-locallisppath=%emacs_dir%/../site-lisp '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
  electric-indent-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 f f a p <return> M-x r - e - b <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
if: Symbol's function definition is void: cl-member
Eager macro-expansion failure: (void-function cl-sublis) [2 times]

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message format-spec rfc822 mml easymenu
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
easy-mmode nnheader gmm-utils mailheader sendmail derived eieio-core
gnus-util rmail dframe rfc2047 rfc2045 ietf-drums mail-utils mm-util
mail-prsvr cl cl-macs pcase cl-lib gv password-cache url-vars time-date
tooltip electric uniquify 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
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
w32notify w32 multi-tty emacs)

[Message part 2 (text/html, inline)]

[log (application/octet-stream, attachment)]

Message #8 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 18:46:15 +0200

> Date: Tue, 10 Dec 2013 12:13:04 +0000
> From: Richard Copley <rcopley <at> gmail.com>
> 
> Building Emacs from trunk r115447, I get several errors and warnings
> about undefined functions/macros in the cl- namespace. See build output
> attached. For example, byte-compiling "ffap.el" fails with:
> 
> In toplevel form:
> ../../trunk/lisp/ffap.el:108:1:Error: Symbol's function definition is void:
> cl-member
> Makefile:272: recipe for target `ffap.elc' failed
> make[2]: *** [ffap.elc] Error 1

Did you try bootstrap?

Message #11 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 16:53:09 +0000

[Message part 1 (text/plain, inline)]

On 10 Dec 2013 16:46, "Eli Zaretskii" <eliz <at> gnu.org> wrote:
>
> > Date: Tue, 10 Dec 2013 12:13:04 +0000
> > From: Richard Copley <rcopley <at> gmail.com>
> >
> > Building Emacs from trunk r115447, I get several errors and warnings
> > about undefined functions/macros in the cl- namespace. See build output
> > attached. For example, byte-compiling "ffap.el" fails with:
> >
> > In toplevel form:
> > ../../trunk/lisp/ffap.el:108:1:Error: Symbol's function definition is
void:
> > cl-member
> > Makefile:272: recipe for target `ffap.elc' failed
> > make[2]: *** [ffap.elc] Error 1
>
> Did you try bootstrap?
No. It's a pristine working tree. Should I be bootstrapping? I will try it,
anyway. Thanks.

[Message part 2 (text/html, inline)]

Message #16 received at 16099-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 16099-done <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 12:09:44 -0500

I'm confident bootstrap will work for you.
We can reopen this if it does not.

Message #19 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 16099 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#16099: closed (Re: bug#16099: 24.3.50; Build failure,
 undefined function `cl-member')
Date: Tue, 10 Dec 2013 17:42:56 +0000

[Message part 1 (text/plain, inline)]

From: Glenn Morris <rgm <at> gnu.org>

    I'm confident bootstrap will work for you.
    We can reopen this if it does not.

Thanks for your help. So do I now need to be using "make bootstrap" instead
of "make"? Back at bug #14503, Eli told me this:

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

nt/INSTALL still doesn't say anything about needing to use "make bootstrap".

Like I said, I am using a pristine working tree. You know what that means,
right?

[Message part 2 (text/html, inline)]

Message #22 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 16099 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#16099: closed (Re: bug#16099: 24.3.50; Build failure,
 undefined function `cl-member')
Date: Tue, 10 Dec 2013 17:55:59 +0000

[Message part 1 (text/plain, inline)]

"make bootstrap" didn't make any difference.

[Message part 2 (text/html, inline)]

Message #25 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 20:05:08 +0200

> Date: Tue, 10 Dec 2013 16:53:09 +0000
> From: Richard Copley <rcopley <at> gmail.com>
> Cc: 16099 <at> debbugs.gnu.org
> 
> > Did you try bootstrap?
> No. It's a pristine working tree. Should I be bootstrapping?

In a pristine tree, the first "make" bootstraps.

I'm unsure what the problem could be, I see none.

Message #28 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 16099 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 13:12:57 -0500

What's going on here:

  Buffer is read-only: #<buffer cus-load.el>
  [...]
  Buffer is read-only: #<buffer finder-inf.el>
  [...]
  Opening output file: no such file or directory, c:/c/emacs/trunk/lisp/loaddefs.el
  [...]
  loaddefs.el: No such file or directory

?

Message #31 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 18:13:17 +0000

[Message part 1 (text/plain, inline)]

On 10 Dec 2013 18:05, "Eli Zaretskii" <eliz <at> gnu.org> wrote:
>
> > Date: Tue, 10 Dec 2013 16:53:09 +0000
> > From: Richard Copley <rcopley <at> gmail.com>
> > Cc: 16099 <at> debbugs.gnu.org
> >
> > > Did you try bootstrap?
> > No. It's a pristine working tree. Should I be bootstrapping?
>
> In a pristine tree, the first "make" bootstraps.
>
> I'm unsure what the problem could be, I see none.

Ok, thanks. Have you successfully bootstrapped recently?

[Message part 2 (text/html, inline)]

Message #34 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: rgm <at> gnu.org, 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: closed (Re: bug#16099: 24.3.50;
 Build failure, undefined function `cl-member')
Date: Tue, 10 Dec 2013 20:13:26 +0200

> Date: Tue, 10 Dec 2013 17:42:56 +0000
> From: Richard Copley <rcopley <at> gmail.com>
> Cc: 16099 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> 
> From: Glenn Morris <rgm <at> gnu.org>
> 
>     I'm confident bootstrap will work for you.
>     We can reopen this if it does not.
> 
> Thanks for your help. So do I now need to be using "make bootstrap" instead
> of "make"?

No, not the first time you build in a fresh checkout.

Message #39 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 13:16:38 -0500

Richard Copley wrote:

> Ok, thanks. Have you successfully bootstrapped recently?

On a daily basis, and 1 minute ago just to check.

(Normally I could point to
http://hydra.nixos.org/jobset/gnu/emacs-trunk

but it is having one of its sulking fits, sigh.)

Message #42 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 16099 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 18:25:11 +0000

[Message part 1 (text/plain, inline)]

On 10 Dec 2013 18:12, "Glenn Morris" <rgm <at> gnu.org> wrote:
>
>
> What's going on here:
>
>   Buffer is read-only: #<buffer cus-load.el>
>   [...]
>   Buffer is read-only: #<buffer finder-inf.el>
>   [...]
>   Opening output file: no such file or directory,
c:/c/emacs/trunk/lisp/loaddefs.el
>   [...]
>   loaddefs.el: No such file or directory
>
> ?

That certainly looks suspect, well spotted. I guess
"c:/c/emacs/trunk/lisp/loaddefs.el" is the value of
`generated-autoload-file' which is set a few lines up:

[...] --eval '(setq generated-autoload-file (expand-file-name
"/c/emacs/trunk/lisp/loaddefs.el"))' [...]

I think that's probably a bug (mixing MSYS- and native-style paths), but if
I had used a relative path to invoke the configure script, it would have
been a benign bug. I'll reconfigure using a relative path and try again.

[Message part 2 (text/html, inline)]

Message #45 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: rgm <at> gnu.org, 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 20:34:34 +0200

> Date: Tue, 10 Dec 2013 18:25:11 +0000
> From: Richard Copley <rcopley <at> gmail.com>
> Cc: 16099 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> 
> >   Opening output file: no such file or directory,
> c:/c/emacs/trunk/lisp/loaddefs.el
> >   [...]
> >   loaddefs.el: No such file or directory
> >
> > ?
> 
> That certainly looks suspect, well spotted. I guess
> "c:/c/emacs/trunk/lisp/loaddefs.el" is the value of
> `generated-autoload-file' which is set a few lines up:
> 
> [...] --eval '(setq generated-autoload-file (expand-file-name
> "/c/emacs/trunk/lisp/loaddefs.el"))' [...]
> 
> I think that's probably a bug (mixing MSYS- and native-style paths), but if
> I had used a relative path to invoke the configure script, it would have
> been a benign bug. I'll reconfigure using a relative path and try again.

Instead of working around the problem, just add a call to
unmsys--file-name there, like we do for other autoloads in that
Makefile.

Message #48 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 20:35:34 +0200

> Date: Tue, 10 Dec 2013 18:13:17 +0000
> From: Richard Copley <rcopley <at> gmail.com>
> Cc: 16099 <at> debbugs.gnu.org
> 
> > In a pristine tree, the first "make" bootstraps.
> >
> > I'm unsure what the problem could be, I see none.
> 
> Ok, thanks. Have you successfully bootstrapped recently?

Just now.  But I build in-tree, so $(srcdir) is "." and your problem
doesn't rear its ugly head.

Message #51 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 18:37:36 +0000

[Message part 1 (text/plain, inline)]

On 10 December 2013 18:34, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Instead of working around the problem, just add a call to
> unmsys--file-name there, like we do for other autoloads in that
> Makefile.
>

A much better idea, thanks.
I won't provide a patch, for copyright reasons. Sorry about that.

[Message part 2 (text/html, inline)]

Message #54 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Richard Copley <rcopley <at> gmail.com>, 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 13:42:23 -0500

Eli Zaretskii wrote:

> Instead of working around the problem, just add a call to
> unmsys--file-name there, like we do for other autoloads in that
> Makefile.

Other options might be for configure to abort on MinGW if srcdir is
absolute and has the "wrong" format (which must means that the user
specified srcdir, as in this case). Or to simply fix such a srcdir
before generating the Makefiles.

Might be easier than unmsys'ing every present and future instance of
srcdir in the Makefiles.

Message #57 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Richard Copley <rcopley <at> gmail.com>, 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 13:48:28 -0500

Glenn Morris wrote:

> Other options might be for configure to abort on MinGW if srcdir is
> absolute and has the "wrong" format (which must means that the user
> specified srcdir, as in this case). Or to simply fix such a srcdir
> before generating the Makefiles.
>
> Might be easier than unmsys'ing every present and future instance of
> srcdir in the Makefiles.

In fact I think that might mean that you could remove unmsys--file-name
altogether...?

Message #62 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: rcopley <at> gmail.com, 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 20:58:32 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Richard Copley <rcopley <at> gmail.com>,  16099 <at> debbugs.gnu.org
> Date: Tue, 10 Dec 2013 13:42:23 -0500
> 
> Eli Zaretskii wrote:
> 
> > Instead of working around the problem, just add a call to
> > unmsys--file-name there, like we do for other autoloads in that
> > Makefile.
> 
> Other options might be for configure to abort on MinGW if srcdir is
> absolute and has the "wrong" format (which must means that the user
> specified srcdir, as in this case).

That would mean we don't support a build outside of the source tree.
Because there's nothing wrong with /c/foo/bar file names.

> Or to simply fix such a srcdir before generating the Makefiles.

Not sure what you suggest here.  Please elaborate.

> Might be easier than unmsys'ing every present and future instance of
> srcdir in the Makefiles.

Not every one, just those in which the /c/ part is not at the
beginning of the command-line argument.  If it is at the beginning
MSYS does the conversion automatically.

Message #65 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: rcopley <at> gmail.com, 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 20:58:52 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Richard Copley <rcopley <at> gmail.com>,  16099 <at> debbugs.gnu.org
> Date: Tue, 10 Dec 2013 13:48:28 -0500
> 
> Glenn Morris wrote:
> 
> > Other options might be for configure to abort on MinGW if srcdir is
> > absolute and has the "wrong" format (which must means that the user
> > specified srcdir, as in this case). Or to simply fix such a srcdir
> > before generating the Makefiles.
> >
> > Might be easier than unmsys'ing every present and future instance of
> > srcdir in the Makefiles.
> 
> In fact I think that might mean that you could remove unmsys--file-name
> altogether...?

Of course, you can't.

Message #68 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: rgm <at> gnu.org, 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 20:59:19 +0200

> Date: Tue, 10 Dec 2013 18:37:36 +0000
> From: Richard Copley <rcopley <at> gmail.com>
> Cc: Glenn Morris <rgm <at> gnu.org>, 16099 <at> debbugs.gnu.org
> 
> > Instead of working around the problem, just add a call to
> > unmsys--file-name there, like we do for other autoloads in that
> > Makefile.
> >
> 
> A much better idea, thanks.
> I won't provide a patch, for copyright reasons. Sorry about that.

But does it work for you?

Message #71 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 21:09:14 +0100

>> Other options might be for configure to abort on MinGW if srcdir is
>> absolute and has the "wrong" format (which must means that the user
>> specified srcdir, as in this case). Or to simply fix such a srcdir
>> before generating the Makefiles.
>>
>> Might be easier than unmsys'ing every present and future instance of
>> srcdir in the Makefiles.
>
> In fact I think that might mean that you could remove unmsys--file-name
> altogether...?

I think that the function 'unmsys--file-name' is conceptually wrong, because:

1. It assumes that every MSYS path will match the "/c/foo/bar"
pattern, which in general is false (as we've already seen).

2. Some directory "c:/whatever" could be mounted in MSYS as "/c/foo",
and therefore "/c/foo/bar" should be translated as "c:/whatever/bar"
(not "c:/foo/bar"). Improbable but possible.

Therefore, like I've said before, IMO this is unreliable, and we
should translate (or "unmsys") _all_ MSYS paths with the 'msys-to-w32'
script.

-- 
Dani Moncayo

Message #74 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 22:31:59 +0200

> Date: Tue, 10 Dec 2013 21:09:14 +0100
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> 
> I think that the function 'unmsys--file-name' is conceptually wrong, because:
> 
> 1. It assumes that every MSYS path will match the "/c/foo/bar"

It does nothing of the kind.  It handles _only_ those file names that
slip into Emacs in the /c/foo/bar form, which Emacs cannot handle.

> pattern, which in general is false (as we've already seen).

Not sure what you meant here.  If you mean your use case of building
inside the MSYS tree, then that one should be (and was) handled by
different means.

> 2. Some directory "c:/whatever" could be mounted in MSYS as "/c/foo",
> and therefore "/c/foo/bar" should be translated as "c:/whatever/bar"
> (not "c:/foo/bar"). Improbable but possible.

People also shoot themselves in the foot, but why should we cater to
suicidal ones?  "If it hurts, don't do that."  MSYS is a tool to build
Posix packages, it has no purpose other than that.  So it makes very
little sense to configure MSYS in a way that interferes with its main
purpose.  People could do that by mistake, of course, but then the
solution is to recognize the mistake and correct it.

> Therefore, like I've said before, IMO this is unreliable, and we
> should translate (or "unmsys") _all_ MSYS paths with the 'msys-to-w32'
> script.

Which is also unreliable, as we've seen.

There are no bullet-proof solutions with MSYS.  Building Posix
packages on Windows is inherently fragile, and always will be.
Therefore, the solutions should be the simplest ones we can find that
do the job.  People who do unreasonable things should be told not to.

Message #77 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 20:47:55 +0000

[Message part 1 (text/plain, inline)]

On 10 December 2013 18:59, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Tue, 10 Dec 2013 18:37:36 +0000
> > From: Richard Copley <rcopley <at> gmail.com>
> > Cc: Glenn Morris <rgm <at> gnu.org>, 16099 <at> debbugs.gnu.org
> >
> > > Instead of working around the problem, just add a call to
> > > unmsys--file-name there, like we do for other autoloads in that
> > > Makefile.
> > >
> >
> > A much better idea, thanks.
> > I won't provide a patch, for copyright reasons. Sorry about that.
>
> But does it work for you?
>

Yes. (I added one call to unmsys--file-name to the autoloads: target's
recipe in lisp/Makefile.in, as you suggested, then built again from an
otherwise pristine checkout. No errors.) Thanks.

[Message part 2 (text/html, inline)]

Message #80 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 21:57:04 +0100

>> I think that the function 'unmsys--file-name' is conceptually wrong, because:
>>
>> 1. It assumes that every MSYS path will match the "/c/foo/bar"
>
> It does nothing of the kind.  It handles _only_ those file names that
> slip into Emacs in the /c/foo/bar form, which Emacs cannot handle.

I think that it would be possible that the path to "unmsys" had the
form "/foo/bar".  For example if someone has the source code tree
under his MSYS tree and invokes the configure script with an absolute
MSYS path (e.g. "/home/user/emacs/trunk/configure").

In that case, 'unmsys--file-name' will not translate the MSYS path
("/home/user/...") as expected.

>> pattern, which in general is false (as we've already seen).
>
> Not sure what you meant here.  If you mean your use case of building
> inside the MSYS tree, then that one should be (and was) handled by
> different means.

It was handled in one place (for generating the native paths in
'src/epaths.h'), but it seems that there are more places where a
translation to native w32 format is performed, and it would be nice if
that translation was as reliable as possible.

>> 2. Some directory "c:/whatever" could be mounted in MSYS as "/c/foo",
>> and therefore "/c/foo/bar" should be translated as "c:/whatever/bar"
>> (not "c:/foo/bar"). Improbable but possible.
>
> People also shoot themselves in the foot, but why should we cater to
> suicidal ones?  "If it hurts, don't do that."  MSYS is a tool to build
> Posix packages, it has no purpose other than that.  So it makes very
> little sense to configure MSYS in a way that interferes with its main
> purpose.  People could do that by mistake, of course, but then the
> solution is to recognize the mistake and correct it.

Well yes, this second problem is minor, but we could fix it with the
same effort.

>> Therefore, like I've said before, IMO this is unreliable, and we
>> should translate (or "unmsys") _all_ MSYS paths with the 'msys-to-w32'
>> script.
>
> Which is also unreliable, as we've seen.
>
> There are no bullet-proof solutions with MSYS.  Building Posix
> packages on Windows is inherently fragile, and always will be.
> Therefore, the solutions should be the simplest ones we can find that
> do the job.  People who do unreasonable things should be told not to.

I agree that the MSYS shell auto-conversion of paths can be tricky,
but we still don't know the origin of this problem.

In any case, the problem I pointed out doesn't seem to be the problem
reported by the OP.

Perhaps it would be interesting to see the file 'src/epaths.h'
produced in the failed build.  If some path is wrong there, then
_maybe_ the culprit could be the script 'msys-to-w32'.

-- 
Dani Moncayo

Message #85 received at 16099-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: rgm <at> gnu.org, 16099-done <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 22:58:26 +0200

> Date: Tue, 10 Dec 2013 20:47:55 +0000
> From: Richard Copley <rcopley <at> gmail.com>
> Cc: Glenn Morris <rgm <at> gnu.org>, 16099 <at> debbugs.gnu.org
> 
> > > > Instead of working around the problem, just add a call to
> > > > unmsys--file-name there, like we do for other autoloads in that
> > > > Makefile.
> > > >
> > >
> > > A much better idea, thanks.
> > > I won't provide a patch, for copyright reasons. Sorry about that.
> >
> > But does it work for you?
> >
> 
> Yes. (I added one call to unmsys--file-name to the autoloads: target's
> recipe in lisp/Makefile.in, as you suggested, then built again from an
> otherwise pristine checkout. No errors.) Thanks.

Thanks, installed.

Message #88 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 16:08:17 -0500

Eli Zaretskii wrote:

>> Yes. (I added one call to unmsys--file-name to the autoloads: target's
>> recipe in lisp/Makefile.in, as you suggested, then built again from an
>> otherwise pristine checkout. No errors.) Thanks.
>
> Thanks, installed.

You should do cus-load and finder-inf likewise.

Message #91 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Wed, 11 Dec 2013 19:07:16 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: 16099 <at> debbugs.gnu.org
> Date: Tue, 10 Dec 2013 16:08:17 -0500
> 
> Eli Zaretskii wrote:
> 
> >> Yes. (I added one call to unmsys--file-name to the autoloads: target's
> >> recipe in lisp/Makefile.in, as you suggested, then built again from an
> >> otherwise pristine checkout. No errors.) Thanks.
> >
> > Thanks, installed.
> 
> You should do cus-load and finder-inf likewise.

Thanks, done.

Message #94 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Wed, 11 Dec 2013 19:12:02 +0200

> Date: Tue, 10 Dec 2013 21:57:04 +0100
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> 
> I think that it would be possible that the path to "unmsys" had the
> form "/foo/bar".  For example if someone has the source code tree
> under his MSYS tree and invokes the configure script with an absolute
> MSYS path (e.g. "/home/user/emacs/trunk/configure").
> 
> In that case, 'unmsys--file-name' will not translate the MSYS path
> ("/home/user/...") as expected.

How is this different from your use case, which is already handled?

> > Not sure what you meant here.  If you mean your use case of building
> > inside the MSYS tree, then that one should be (and was) handled by
> > different means.
> 
> It was handled in one place (for generating the native paths in
> 'src/epaths.h'), but it seems that there are more places where a
> translation to native w32 format is performed, and it would be nice if
> that translation was as reliable as possible.

Does it make any trouble?  If so, please report the details (and I
still don't understand how it works for you, since that's exactly what
you do).

If we have no specific problems, let's leave this alone, since it is
not broken.  Our aim is not to translate file names, or aim is to
build Emacs reliably and correctly.

> > People also shoot themselves in the foot, but why should we cater to
> > suicidal ones?  "If it hurts, don't do that."  MSYS is a tool to build
> > Posix packages, it has no purpose other than that.  So it makes very
> > little sense to configure MSYS in a way that interferes with its main
> > purpose.  People could do that by mistake, of course, but then the
> > solution is to recognize the mistake and correct it.
> 
> Well yes, this second problem is minor, but we could fix it with the
> same effort.

It is not a problem at all, and therefore isn't worth wasting time and
energy.

> I agree that the MSYS shell auto-conversion of paths can be tricky,
> but we still don't know the origin of this problem.

What problem are you talking about?  The lack of auto-conversion?  Its
origin is well known: MSYS simply tries to play it safe, and doesn't
auto-convert unless it is absolutely sure it sees a file name.

Message #97 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Thu, 12 Dec 2013 15:08:08 +0100

[Message part 1 (text/plain, inline)]

On Wed, Dec 11, 2013 at 6:12 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Tue, 10 Dec 2013 21:57:04 +0100
>> From: Dani Moncayo <dmoncayo <at> gmail.com>
>>
>> I think that it would be possible that the path to "unmsys" had the
>> form "/foo/bar".  For example if someone has the source code tree
>> under his MSYS tree and invokes the configure script with an absolute
>> MSYS path (e.g. "/home/user/emacs/trunk/configure").
>>
>> In that case, 'unmsys--file-name' will not translate the MSYS path
>> ("/home/user/...") as expected.
>
> How is this different from your use case, which is already handled?

The difference is this:  I invoke the configure script (from the build
dir) using a relative path, which works with the current trunk.  But
if someone invokes the configure script using an absolute path which
doesn't match the "/c/foo/bar" pattern (e.g.
"/home/user-foo/emacs/trunk/configure"), the build will fail.

I've myself reproduced the problem this morning (visit the attached
file "bootstrap1.log" and look there for "unmsys" - you'll see the
problem clearly).

>> > Not sure what you meant here.  If you mean your use case of building
>> > inside the MSYS tree, then that one should be (and was) handled by
>> > different means.
>>
>> It was handled in one place (for generating the native paths in
>> 'src/epaths.h'), but it seems that there are more places where a
>> translation to native w32 format is performed, and it would be nice if
>> that translation was as reliable as possible.
>
> Does it make any trouble?  If so, please report the details (and I
> still don't understand how it works for you, since that's exactly what
> you do).

This is answered above.  Again: the problem arises with _absolute_
MSYS path which don't match the "/c/foo/bar" pattern.

> If we have no specific problems, let's leave this alone, since it is
> not broken.  Our aim is not to translate file names, or aim is to
> build Emacs reliably and correctly.

Indeed, that is our aim, and for that reason I'd like to make the MSYS
build procedure more reliable/robust than is right now, and I think I
know how to do it (see below).

>> I agree that the MSYS shell auto-conversion of paths can be tricky,
>> but we still don't know the origin of this problem.
>
> What problem are you talking about?  The lack of auto-conversion?  Its
> origin is well known: MSYS simply tries to play it safe, and doesn't
> auto-convert unless it is absolutely sure it sees a file name.

Well, I've been reading a bit about the rules used by the MSYS bash
for auto-translating posix-type PATHS to Windows native paths [1], and
I think I now understand the problem.

Ideally, the MSYS bash should be smart enough to correctly translate
paths as needed when invoking native w32 programs, but the behavior is
not always what we want.  For example, in 'lisp/Makefile.in' we have:

 custom-deps: doit
    $(setwins_almost); \
    echo Directories: $$wins; \
    $(emacs) -l cus-dep \
     --eval '(setq generated-custom-dependencies-file
(unmsys--file-name "$(srcdir)/cus-load.el"))' \
     -f custom-make-dependencies $$wins

You had to try to manually translate the path "$(srcdir)/cus-load.el"
with 'unmsys--file-name' because the MSYS bash didn't do it
automatically as expected (if the path was a standalone argument, it
would have been translated as expected, but the path is part of a more
complex argument, and MSYS doesn't handle that case well.).

But your way of implementing the translation doesn't work with all
types of MSYS paths, as we've already seen.

After doing some test, I've got a path that seems to fix this problem
(see "patch.v3.diff" attached).

The file "bootstrap2.log" is the output of my "make bootstrap" with
the patch applied.  You can compare it with "bootstrap1.log" to see
how the problems are indeed fixed.

If you think it is correct, I may commit it to the trunk.

PS: The only "tricky" part of the patch is this:

  leimdir=`${srcdir}/../build-aux/msys-to-w32 "${leimdir}"` && \
  ${RUN_EMACS} -l international/quail \
    --eval "(update-leim-list-file \"$${leimdir}\");"
                                                   ^
                                                   ^
                                                   ^
This semicolon does not alter the effect of the lisp expression, but
prevents MSYS from altering the argument, since such argument (in the
MSYS case) will have a colon ("c:/foo/bar") and that would make MSYS
think about it as a list of posix paths which need translation to
native windows format.  See the rules in [1].  (This technique has
been employed in several points)

-- 
Dani Moncayo

[1] http://www.mingw.org/wiki/Posix_path_conversion

[files.zip (application/zip, attachment)]

Message #100 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Thu, 12 Dec 2013 18:33:43 +0200

> Date: Thu, 12 Dec 2013 15:08:08 +0100
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: 16099 <at> debbugs.gnu.org
> 
> >> In that case, 'unmsys--file-name' will not translate the MSYS path
> >> ("/home/user/...") as expected.
> >
> > How is this different from your use case, which is already handled?
> 
> The difference is this:  I invoke the configure script (from the build
> dir) using a relative path, which works with the current trunk.  But
> if someone invokes the configure script using an absolute path which
> doesn't match the "/c/foo/bar" pattern (e.g.
> "/home/user-foo/emacs/trunk/configure"), the build will fail.

The "pwd -W" method worked with both.  I understand that the
msys-to-w32 method broke that.  Then please un-break it.

> But your way of implementing the translation doesn't work with all
> types of MSYS paths, as we've already seen.

It isn't supposed to.

> PS: The only "tricky" part of the patch is this:
> 
>   leimdir=`${srcdir}/../build-aux/msys-to-w32 "${leimdir}"` && \
>   ${RUN_EMACS} -l international/quail \
>     --eval "(update-leim-list-file \"$${leimdir}\");"
>                                                    ^
>                                                    ^
>                                                    ^
> This semicolon does not alter the effect of the lisp expression, but
> prevents MSYS from altering the argument, since such argument (in the
> MSYS case) will have a colon ("c:/foo/bar") and that would make MSYS
> think about it as a list of posix paths which need translation to
> native windows format.  See the rules in [1].  (This technique has
> been employed in several points)

I don't think we should rely on such fragility.

Message #103 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Thu, 12 Dec 2013 20:53:29 +0100

[Message part 1 (text/plain, inline)]

>> >> In that case, 'unmsys--file-name' will not translate the MSYS path
>> >> ("/home/user/...") as expected.
>> >
>> > How is this different from your use case, which is already handled?
>>
>> The difference is this:  I invoke the configure script (from the build
>> dir) using a relative path, which works with the current trunk.  But
>> if someone invokes the configure script using an absolute path which
>> doesn't match the "/c/foo/bar" pattern (e.g.
>> "/home/user-foo/emacs/trunk/configure"), the build will fail.
>
> The "pwd -W" method worked with both.  I understand that the
> msys-to-w32 method broke that.

No, the msys-to-w32 method didn't broke that.  It was at revno 114990
(which is not mine, BTW).

> Then please un-break it.

The attached patch seems to be what you want (I've tested it and works fine).

>> But your way of implementing the translation doesn't work with all
>> types of MSYS paths, as we've already seen.
>
> It isn't supposed to.
>
>> PS: The only "tricky" part of the patch is this:
>>
>>   leimdir=`${srcdir}/../build-aux/msys-to-w32 "${leimdir}"` && \
>>   ${RUN_EMACS} -l international/quail \
>>     --eval "(update-leim-list-file \"$${leimdir}\");"
>>                                                    ^
>>                                                    ^
>>                                                    ^
>> This semicolon does not alter the effect of the lisp expression, but
>> prevents MSYS from altering the argument, since such argument (in the
>> MSYS case) will have a colon ("c:/foo/bar") and that would make MSYS
>> think about it as a list of posix paths which need translation to
>> native windows format.  See the rules in [1].  (This technique has
>> been employed in several points)
>
> I don't think we should rely on such fragility.

Ok, I agree that it is fragile.

I don't like the current approach either, but it seems better that the
above one, yes.

So I'll wait for you to validate the attached patch.

-- 
Dani Moncayo

[tmp.diff (text/plain, attachment)]

Message #106 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Sat, 14 Dec 2013 10:33:29 +0100

> So I'll wait for you to validate the attached patch.

It seems that I was waiting in vain, so I've just committed the patch.

-- 
Dani Moncayo

Message #109 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Sat, 14 Dec 2013 11:56:00 +0200

> Date: Sat, 14 Dec 2013 10:33:29 +0100
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> 
> > So I'll wait for you to validate the attached patch.
> 
> It seems that I was waiting in vain, so I've just committed the patch.

Thanks.

Message #112 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Sat, 14 Dec 2013 15:08:26 -0500

The only comment I'd make is: can you restrict doing this to when srcdir
is absolute to start with? Which must mean the user has specified an
absolute path to configure's srcdir, which I would imagine to be rare.
On Unix systems, this would be trivial - just check if srcdir starts
with "/". I don't know what you need to do for MS.

Forcing srcdir to be absolute all the time will eg break using a srcdir
with spaces in.

Message #115 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Sat, 14 Dec 2013 22:32:36 +0100

On Sat, Dec 14, 2013 at 9:08 PM, Glenn Morris <rgm <at> gnu.org> wrote:
>
> The only comment I'd make is: can you restrict doing this to when srcdir
> is absolute to start with? Which must mean the user has specified an
> absolute path to configure's srcdir, which I would imagine to be rare.
> On Unix systems, this would be trivial - just check if srcdir starts
> with "/". I don't know what you need to do for MS.

I think that the patch below would do it.

> Forcing srcdir to be absolute all the time will eg break using a srcdir
> with spaces in.

I don't understand this.  For example if the original value of srcdir
was "../my nice repo", with the current trunk it would be translated
to something like "/c/foo/bar/my nice repo".  What breakage might it
cause?


diff --git a/configure.ac b/configure.ac
index 2e9eee6..0c4b98b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -28,11 +28,14 @@ if test "x$MSYSTEM" = "xMINGW32"
 then
    . $srcdir/nt/mingw-cfg.site

-   # Convert srcdir to an absolute MSYS path of the form "/c/foo/bar"
-   # to simplify later conversions of paths to windows-native format
-   # "c:/foo/bar"
-   srcdir=`cd "${srcdir}" && pwd -W`
-   srcdir="/${srcdir:0:1}${srcdir:2}"
+   if test ${srcdir:0:1} = "/" -o ${srcdir:1:1} = ":"
+   then
+       # srcdir is an absolute path.  In this case, force the format
+       # "/c/foo/bar", to simplify later conversions to native Windows
+       # format ("c:/foo/bar")
+       srcdir=`cd "${srcdir}" && pwd -W`
+       srcdir="/${srcdir:0:1}${srcdir:2}"
+   fi
 fi

 dnl Set emacs_config_options to the options of 'configure', quoted
for the shell,

-- 
Dani Moncayo

Message #118 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Sat, 14 Dec 2013 16:43:05 -0500

Dani Moncayo wrote:

> was "../my nice repo", with the current trunk it would be translated
> to something like "/c/foo/bar/my nice repo".  What breakage might it
> cause?

You're right, that doesn't work either way.
But if making srcdir absolute introduces spaces that were not otherwise
there (eg srcdir was "." but is now "/path/to whatever"), that breaks
something that otherwise works.

> +   if test ${srcdir:0:1} = "/" -o ${srcdir:1:1} = ":"

Is substring syntax portable? Normally I'd use something like:

case $srcdir in
  /* | .:*) ... ;;
esac

But maybe MinGW /bin/sh is always /bin/bash, in which case it's
irrelevant.

Message #121 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 16099 <at> debbugs.gnu.org
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Sat, 14 Dec 2013 22:56:13 +0100

>> was "../my nice repo", with the current trunk it would be translated
>> to something like "/c/foo/bar/my nice repo".  What breakage might it
>> cause?
>
> You're right, that doesn't work either way.
> But if making srcdir absolute introduces spaces that were not otherwise
> there (eg srcdir was "." but is now "/path/to whatever"), that breaks
> something that otherwise works.

Ah ok, I didn't think about that possibility.  I will commit the patch then.

>> +   if test ${srcdir:0:1} = "/" -o ${srcdir:1:1} = ":"
>
> Is substring syntax portable? Normally I'd use something like:
>
> case $srcdir in
>   /* | .:*) ... ;;
> esac
>
> But maybe MinGW /bin/sh is always /bin/bash, in which case it's
> irrelevant.

MSYS has (a special port of) GNU bash, and it seems to be the only
available shell.  So I think we can assume that shell on any MSYS
environment.

-- 
Dani Moncayo

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.