GNU bug report logs - #18955
Makefile:382: recipe for target 'src' failed

Previous Next

Full log

View this message in rfc822 format

From: Alexander Shukaev <haroogan <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 18955 <at> debbugs.gnu.org
Subject: bug#18955: Makefile:382: recipe for target 'src' failed
Date: Sun, 9 Nov 2014 18:42:06 +0100

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

>
> Is this problem still happening?  If so, did you try using
> unmsys--file-name to solve it?
>

The problem is of course happening. I've also discovered why it does not
happen in `trunk'. The reason is that due to "FORCE" phony, this target is
simply never run in the `trunk'. Furthermore, since "macuvs.h" already
exists and is under source control, as a temporary fix, I simply decided to
disable this target similarly to `trunk', until the appropriate fix is
found.

Sorry, but I haven't tried `unmsys--file-name' yet.

To be honest, from my point of view, workarounds like `unmsys--file-name'
all over the place are not a good idea. Look at the path passed:

/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/admin/unidata/IVD_Sequences.txt


I get it that on Windows, Emacs currently gets confused and as a last
resort tries to prepend "c:", hence:

Opening input file: no such file or directory,
> c:/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/admin/unidata/IVD_Sequences.txt


I believe it's better to teach it to treat "/C" as "C:" by default, i.e. to
accept both variants because there is no ambiguity here and, as a result,
it will support both Windows and MSYS(2)/Cygwin paths out of the box.

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

Previous Next

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