bug#18955: Makefile:382: recipe for target 'src' failed

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

Hello,

The `emacs-24' branch cannot be built on Windows (at least in the MSYS2
environment), because of the following error:

Saving file
> c:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/loaddefs.el...
> Wrote
> c:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/loaddefs.el
> Saving file
> c:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/org/org-loaddefs.el...
> Wrote
> c:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/org/org-loaddefs.el
> Saving file
> c:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/eshell/esh-groups.el...
> Wrote
> c:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/eshell/esh-groups.el
> Saving file
> c:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/emacs-lisp/cl-loaddefs.el...
> Wrote
> c:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/emacs-lisp/cl-loaddefs.el
> Saving file
> c:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/cedet/srecode/loaddefs.el...
> Wrote
> c:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/cedet/srecode/loaddefs.el
> Saving file
> c:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/cedet/semantic/loaddefs.el...
> Wrote
> c:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/cedet/semantic/loaddefs.el
> Saving file
> c:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/cedet/ede/loaddefs.el...
> Wrote
> c:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/cedet/ede/loaddefs.el
> Saving file
> c:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/calc/calc-loaddefs.el...
> Wrote
> c:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/calc/calc-loaddefs.el
> (No changes need to be saved)
> make[2]: Leaving directory
> '/c/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/.build/x86_64-w64-mingw32/lisp'
> make[1]: Leaving directory
> '/c/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/.build/x86_64-w64-mingw32/src'
> Makefile:382: recipe for target 'src' failed
> make: *** [src] Error 2


This error has been there for several months by now. There was a discussion
on it in September [1], and it seems like nothing has changed. Please, note
that the `master' branch can be built just fine.

Regards,
Alexander

[1]: https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00387.html

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Glenn Morris]

Alexander Shukaev wrote:

> [1]: https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00387.html

I don't see any evidence in the output you quote to show what the
problem is. If you think it is the same issue as in that link, then
follow the solution from that same thread:

https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00393.html

This issue is already fixed in trunk. I don't see the point backporting
it to emacs-24, so if that is the issue, there is nothing to do here.

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

>
> I don't see any evidence in the output you quote to show what the
> problem is. If you think it is the same issue as in that link, then
> follow the solution from that same thread:
>

I just thought that it might give you some clue on what's going on.


> This issue is already fixed in trunk. I don't see the point backporting
> it to emacs-24, so if that is the issue, there is nothing to do here.
>

I guess this issue is indeed different since the output is different. What
would you need from me to track it down?

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Glenn Morris]

Alexander Shukaev wrote:

> I guess this issue is indeed different since the output is different. What
> would you need from me to track it down?

You need to look back up the make output until you find the actual
error.

bug#18955: Fwd: bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

>
> Makefile:39: recipe for target
> '/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/src/macuvs.h'
> failed
> make[2]: ***
> [/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/src/macuvs.h]
> Error 127
> make[2]: *** Waiting for unfinished jobs....


This file is empty. I can see in the diff that it contained some byte
array, but during building it became absolutely empty. Got an idea what's
going on?

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

Also:

Makefile:594: recipe for target
> '/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/src/../lisp/international/charprop.el'
> failed
> make[1]: ***
> [/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/src/../lisp/international/charprop.el]
> Error 2
> make[1]: *** Waiting for unfinished jobs....

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Glenn Morris]

I think you better send the entire build log as a (compressed) attachment.
Thanks.
But do try starting from a clean state first (`make maintainer-clean').

bug#18955: Fwd: bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii]

> Date: Wed, 5 Nov 2014 18:33:44 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> 
>     Makefile:39: recipe for target
>     '/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/src/macuvs.h'
>     failed
>     make[2]: ***
>     [/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/src/macuvs.h]
>     Error 127
>     make[2]: *** Waiting for unfinished jobs....
> 
> This file is empty. I can see in the diff that it contained some byte array,
> but during building it became absolutely empty. Got an idea what's going on? 

That file is supposed to be generated by uvs.el.

If you delete it and then re-run "make", do you see this rule in
action:

  $(srcdir)/macuvs.h $(lispsource)/international/charprop.el: \
    bootstrap-emacs$(EXEEXT)
	  cd ../admin/unidata && $(MAKE) $(MFLAGS) all EMACS="../$(bootstrap_exe)"

If so, are there any error messages when this rule runs?

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

It turns out that after deleting "macuvs.h", Emacs build has finished
successfully. However, regarding the following rule:

$(srcdir)/macuvs.h $(lispsource)/international/charprop.el: \
>   bootstrap-emacs$(EXEEXT)
> cd ../admin/unidata && $(MAKE) $(MFLAGS) all EMACS="../$(bootstrap_exe)"


I didn't see Make entering "../admin/unidata", so probably the rule was
skipped...

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii]

> Date: Wed, 5 Nov 2014 23:41:16 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: 18955@debbugs.gnu.org
> 
> It turns out that after deleting "macuvs.h", Emacs build has finished
> successfully. However, regarding the following rule:
> 
>     $(srcdir)/macuvs.h $(lispsource)/international/charprop.el: \
>     bootstrap-emacs$(EXEEXT)
>     cd ../admin/unidata && $(MAKE) $(MFLAGS) all EMACS="../$(bootstrap_exe)"
> 
> I didn't see Make entering "../admin/unidata", so probably the rule was
> skipped...

I think this file was built by the rules in admin/unidata/Makefile.

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

So what do we do with this problem? Would you need anything else to test
from me or you already know how to fix it?

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii]

> Date: Thu, 6 Nov 2014 14:17:25 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: 18955@debbugs.gnu.org, rgm@gnu.org
> 
> So what do we do with this problem?

I think we should close it.

> Would you need anything else to test from me or you already know how
> to fix it?

Nothing is needed, thanks.  Not unless the problem returns.

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

>
> I think we should close it.
>

But I can't build Emacs 24 with the first Make run (only by manually
deleting the header and rerunning Make) as I do with Emacs 25 from trunk.
Is it fine by you?

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii]

> Date: Thu, 6 Nov 2014 19:48:32 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: 18955@debbugs.gnu.org, rgm@gnu.org
> 
> But I can't build Emacs 24 with the first Make run (only by manually deleting
> the header and rerunning Make) as I do with Emacs 25 from trunk. Is it fine by
> you?

Sorry, I'm confused now: didn't you say that once the (empty) file was
deleted, the problem disappeared and the build succeeded?  I thought
that the problem disappeared for good.

Sorry for my misunderstanding.

What do you mean by "the first Make run"?  Bootstrapping a newly
checked-out tree?  That works for me, I just tried with the latest
emacs-24 branch.  If it doesn't work for you, then please do send the
log of the entire configure and build process (as a compressed
attachment) starting from a clean checkout of the emacs-24 branch.

Also, are you saying that src/macuvs.h, which is a versioned file, is
somehow emptied by the build process, even though when you check it
out, it is not empty?

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

>
> Also, are you saying that src/macuvs.h, which is a versioned file, is
> somehow emptied by the build process, even though when you check it
> out, it is not empty?


Exactly!

I'm in the middle of something now. I will send log a bit later.

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

Just tried again from scratch and again the same problem. This is certainly
some kind of bug. Attaching logs. Search for "error" in "make.log".

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

[-- Attachment #2: logs.zip --]
[-- Type: application/zip, Size: 89336 bytes --]

bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii]

> Date: Fri, 7 Nov 2014 16:02:12 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: 18955@debbugs.gnu.org, rgm@gnu.org
> 
> Just tried again from scratch and again the same problem. This is certainly
> some kind of bug. Attaching logs. Search for "error" in "make.log".

The error I see is here:

> sed -e 's/\([^;]*\);\(.*\)/(#x\1 "\2")/' -e 's/;/" "/g' < /C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/admin/unidata/UnicodeData.txt > unidata.txt
> Makefile:39: recipe for target '/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/src/macuvs.h' failed
> make[2]: *** [/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/src/macuvs.h] Error 127
> make[2]: *** Waiting for unfinished jobs....

I see no problem in the Sed command which evidently failed.  If you
run the same command from the Bash prompt, does it work?

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

>
> I see no problem in the Sed command which evidently failed.  If you
> run the same command from the Bash prompt, does it work?
>

What makes you think that Sed failed? It runs fine from terminal.
Furthermore, it says line 39, so it's this:

${EMACS} -batch -l "${srcdir}/uvs.el" \
  --eval '(uvs-print-table-ivd "${srcdir}/IVD_Sequences.txt"
"Adobe-Japan1")' \
  > $@

what actually failed.

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

And by the way it explain why "macuvs.h" becomes empty as I stated earlier.

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii]

> Date: Fri, 7 Nov 2014 16:34:51 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: 18955@debbugs.gnu.org, rgm@gnu.org
> 
> What makes you think that Sed failed?

The error message immediately follows the Sed command line, and you
didn't say you ran a parallel "make".

> ${EMACS} -batch -l "${srcdir}/uvs.el" \
> --eval '(uvs-print-table-ivd "${srcdir}/IVD_Sequences.txt" "Adobe-Japan1")' \
> > $@
> 
> what actually failed.

Does that one fail if you run it from the Bash prompt?

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

I found what's going on by running the command manually:

src/bootstrap-emacs.exe -batch -l
"/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/admin/unidata/uvs.el"
--eval '(uvs-print-table-ivd
"/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/admin/unidata/IVD_Sequences.txt"
"Adobe-Japan1")' >
/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/src/macuvs.h
Loading macroexp.elc...
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

The path gets messed up somehow.

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

Why the same does not happen in trunk?

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii]

> Date: Fri, 7 Nov 2014 16:56:27 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: 18955@debbugs.gnu.org, Glenn Morris <rgm@gnu.org>
> 
> I found what's going on by running the command manually:
> 
> src/bootstrap-emacs.exe -batch -l
> "/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/admin/unidata/uvs.el"
> --eval '(uvs-print-table-ivd
> "/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/admin/unidata/IVD_Sequences.txt"
> "Adobe-Japan1")' >
> /C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/src/macuvs.h
> Loading macroexp.elc...
> 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
> 
> The path gets messed up somehow.

Sounds like an MSYS thing.  Try using the unmsys--file-name function,
like some targets in lisp/Makefile do.

bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii]

> Date: Fri, 7 Nov 2014 16:57:42 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: 18955@debbugs.gnu.org, Glenn Morris <rgm@gnu.org>
> 
> Why the same does not happen in trunk?

No clue.

bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii]

> Date: Fri, 7 Nov 2014 16:56:27 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: 18955@debbugs.gnu.org, Glenn Morris <rgm@gnu.org>
> 
> I found what's going on by running the command manually:
> 
> src/bootstrap-emacs.exe -batch -l
> "/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/admin/unidata/uvs.el"
> --eval '(uvs-print-table-ivd
> "/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/admin/unidata/IVD_Sequences.txt"
> "Adobe-Japan1")' >
> /C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/src/macuvs.h
> Loading macroexp.elc...
> 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
> 
> The path gets messed up somehow.

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

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

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii]

> Date: Sun, 9 Nov 2014 18:42:06 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: 18955@debbugs.gnu.org, Glenn Morris <rgm@gnu.org>
> 
> 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

It's not Emacs who becomes confused, it's MSYS.  When MSYS invokes a
native Windows program, it converts /c/foo/bar file names into the
Windows C:\foo\bar form, because otherwise native Windows programs
will not be able to access such files.  There's some logic in MSYS
that is used to decide when to do this conversion, and that logic
fails when the /c/foo/bar file name is not at the beginning of the
command-line argument, as in this case.  That's why we use
unmsys--file-name: to paper over these failures of MSYS.

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

To do this, we'd have to drag this support all the way down to the
lowest level where we pass file names to the OS APIs.  And then we'd
have to disallow root directories of one letter, like C:/c, which are
entirely legitimate.  All that just to handle the few commands during
the build process that need it.  I find this solution even more ugly
than the unmsys--file-name gork.

IOW, the MSYS build process needs a few ugly tweaks to make it work.
I consider those ugly tweaks a necessary evil, but making ugly hacks
in Emacs per se just to support these tweaks sounds excessive and
unjustified, since the ratio of the number of people who build Emacs
to the number of those who just use it is quite small.  Letting those
many suffer inconveniences and limitations so that the few could live
easier sounds wrong to me.

bug#18955: Makefile:382: recipe for target 'src' failed

[Dani Moncayo]

> It's not Emacs who becomes confused, it's MSYS.  When MSYS invokes a
> native Windows program, it converts /c/foo/bar file names into the
> Windows C:\foo\bar form, because otherwise native Windows programs
> will not be able to access such files.  There's some logic in MSYS
> that is used to decide when to do this conversion, and that logic
> fails when the /c/foo/bar file name is not at the beginning of the
> command-line argument, as in this case.

Indeed, and FWIW, that logic is documented here:

  http://www.mingw.org/wiki/Posix_path_conversion

>  That's why we use
> unmsys--file-name: to paper over these failures of MSYS.
>
>> 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.

MSYS paths are not only those of the form "/c/foo".  For example:
"/home/dani/foo", "/usr/local" and, in general any UNIX-like path are
valid MSYS paths.

And moreover, any MSYS path could be mounted to any Windows-native
path (type "mount" to see the current mapping).

Therefore, it is clear that supporting MSYS/Cygwin paths from the
MS-Windows port of Emacs is far more complex that simply translating
"/C" into "C:".

-- 
Dani Moncayo

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

>
> To do this, we'd have to drag this support all the way down to the
> lowest level where we pass file names to the OS APIs.  And then we'd
> have to disallow root directories of one letter, like C:/c, which are
> entirely legitimate.  All that just to handle the few commands during
> the build process that need it.  I find this solution even more ugly
> than the unmsys--file-name gork.


I'm afraid I don't understand your point here. To reiterate, the current
problem is that Emacs does not know how to treat "/C" in the beginning,
therefore it assumes that the path given does not have a drive letter, so
it add "c:" in front of the given path as a wild guess. The only thing that
I propose to change in that logic is to allow paths which contain a slash +
a single letter in the beginning, e.g. "/C", so that when Emacs sees it, it
simply converts that to "C:" and passes further to old logic of path
manipulation. In other words, nothing has to be changed to the lowest level
as you say. My change involves one `if' statement or so in the very
beginning of the path processing. Furthermore, I don't get it why you would
have to disallow "C:/c"? If somebody passes "C:/c" then it's perfectly
valid Windows path. If somebody passes "/C/c", then according my proposal
it will be converted to "C:/c" and then processed further.

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii]

> Date: Sun, 9 Nov 2014 21:10:58 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Alexander Shukaev <haroogan@gmail.com>, 18955@debbugs.gnu.org
> 
> MSYS paths are not only those of the form "/c/foo".  For example:
> "/home/dani/foo", "/usr/local" and, in general any UNIX-like path are
> valid MSYS paths.
> 
> And moreover, any MSYS path could be mounted to any Windows-native
> path (type "mount" to see the current mapping).
> 
> Therefore, it is clear that supporting MSYS/Cygwin paths from the
> MS-Windows port of Emacs is far more complex that simply translating
> "/C" into "C:".

Right.  Fortunately, these issues are very few and far in-between, so
we handle them with special-purpose tweaks, on a case by case basis.

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

>
> MSYS paths are not only those of the form "/c/foo".  For example:
> "/home/dani/foo", "/usr/local" and, in general any UNIX-like path are
> valid MSYS paths.
>

 These are out of the scope right now. You are actually not supposed to
pass them outside MSYS2 Shells... Nevertheless, even these ones can be
dealt with in future perspective.

Therefore, it is clear that supporting MSYS/Cygwin paths from the
> MS-Windows port of Emacs is far more complex that simply translating
> "/C" into "C:".


Absolute paths which are present everywhere in the daily workflow, not only
during builds, but for instance by invoking Emacs from MSYS/Cygwin shell
and passing paths to it, should definitely be supported, and it is as easy
as my proposal.

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii]

> Date: Sun, 9 Nov 2014 21:13:17 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: 18955@debbugs.gnu.org, Glenn Morris <rgm@gnu.org>
> 
>     To do this, we'd have to drag this support all the way down to the
>     lowest level where we pass file names to the OS APIs. And then we'd
>     have to disallow root directories of one letter, like C:/c, which are
>     entirely legitimate. All that just to handle the few commands during
>     the build process that need it. I find this solution even more ugly
>     than the unmsys--file-name gork.
> 
> I'm afraid I don't understand your point here. To reiterate, the current
> problem is that Emacs does not know how to treat "/C" in the beginning,
> therefore it assumes that the path given does not have a drive letter, so it
> add "c:" in front of the given path as a wild guess.

It's not a wild guess.  File names of the form "/foo/bar" are
legitimate on Windows, so Emacs just adds the current drive to them.

If we treat /c/foo as an alias of C:/foo, users will be unable to
use, say, d:/c/foo directories.  I think this is a limitation that is
better avoided.

> The only thing that I propose to change in that logic is to allow
> paths which contain a slash + a single letter in the beginning,
> e.g. "/C", so that when Emacs sees it, it simply converts that to
> "C:" and passes further to old logic of path manipulation.

There's no single place where the "Emacs sees it" part can happen.
Emacs communicates file names to the OS through quite a few separate
APIs, so all of these places will have to know about this magic.

> In other words, nothing has to be changed to the lowest level as
> you say. My change involves one `if' statement or so in the very beginning of
> the path processing.

There's no single place where "path processing" happens, although
expand-file-name comes close.  So it's not as simple as it sounds.  It
will be quite ugly and viral.

Moreover, when file names are passed to subprocesses, we will need to
convert them as well -- like MSYS does.

> Furthermore, I don't get it why you would have to disallow "C:/c"?
> If somebody passes "C:/c" then it's perfectly valid Windows path. If
> somebody passes "/C/c", then according my proposal it will be
> converted to "C:/c" and then processed further.

That disallows saying something like

  C-x C-f /C/c/foo RET

meaning "/C/c/foo" on the current drive, like we support now.  I don't
think this limitation is justified just to solve several build
problems for which a satisfactory solution already exists.

bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii]

> Date: Sun, 9 Nov 2014 21:25:38 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: 18955@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> 
>     MSYS paths are not only those of the form "/c/foo". For example:
>     "/home/dani/foo", "/usr/local" and, in general any UNIX-like path are
>     valid MSYS paths.
>     
> 
> These are out of the scope right now.

They aren't: if you build Emacs from within the MSYS tree, you will
see them.  The build procedure deals with them as well.

>     Therefore, it is clear that supporting MSYS/Cygwin paths from the
>     MS-Windows port of Emacs is far more complex that simply translating
>     "/C" into "C:".
> 
> Absolute paths which are present everywhere in the daily workflow, not only
> during builds, but for instance by invoking Emacs from MSYS/Cygwin shell and
> passing paths to it, should definitely be supported, and it is as easy as my
> proposal.

People who want Cygwin file names can use the Cygwin build of Emacs.
Or use the cygwin-mount kludge.  There's no clean way to do that in
Emacs proper.  This was discussed several times in the past, so let's
not go there one more time.

Once again, the MSYS build of Emacs works reasonably well, and the
number of places where we need to use ugly kludges like
unmsys--file-name is small.  You have just found one more, it's no big
deal.  It makes little sense to me to complicate Emacs on behalf of
this.

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

>
> Once again, the MSYS build of Emacs works reasonably well, and the
> number of places where we need to use ugly kludges like
> unmsys--file-name is small.  You have just found one more, it's no big
> deal.  It makes little sense to me to complicate Emacs on behalf of
> this.


OK, given the fact that you know where to add `unmsys--file-name' to fix
this issue, this one can be safely closed then.

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Dani Moncayo]

> People who want Cygwin file names can use the Cygwin build of Emacs.
> Or use the cygwin-mount kludge.  There's no clean way to do that in
> Emacs proper.

Evidently.  Cygwin and MSYS have their own filesystems, which the
native MS-Windows port of Emacs doesn't know about, and thus cannot
handle reliably.

-- 
Dani Moncayo

bug#18955: Makefile:382: recipe for target 'src' failed

[Alexander Shukaev]

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

One more question though, if "macuvs.h" is under source control, then why
it is generated during build? Should it actually be generated? As I said,
in the `trunk' this target does not even run.

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

bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii]

> Date: Sun, 09 Nov 2014 22:33:30 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18955@debbugs.gnu.org
> 
> Once again, the MSYS build of Emacs works reasonably well, and the
> number of places where we need to use ugly kludges like
> unmsys--file-name is small.  You have just found one more, it's no big
> deal.

I've just made that rule use unmsys--file-name.

is there anything else that needs to be fixed in this bug report, or
can we close it?

bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii]

> Date: Sun, 9 Nov 2014 21:38:34 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: 18955@debbugs.gnu.org, Glenn Morris <rgm@gnu.org>
> 
> OK, given the fact that you know where to add `unmsys--file-name' to fix this
> issue, this one can be safely closed then.

Thanks, closing.

bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii]

> Date: Sun, 9 Nov 2014 21:43:59 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: 18955@debbugs.gnu.org, Glenn Morris <rgm@gnu.org>
> 
> One more question though, if "macuvs.h" is under source control, then why it is
> generated during build? Should it actually be generated? As I said, in the
> `trunk' this target does not even run.

The rule is there for when IVD_Sequences.txt changes at some future
date.

I don't know why we keep macuvs.h in the repository; Glenn, can you
answer that?

bug#18955: Makefile:382: recipe for target 'src' failed

[Glenn Morris]

Eli Zaretskii wrote:

> I don't know why we keep macuvs.h in the repository; Glenn, can you
> answer that?

I didn't actually know that we did! :)

bug#18955: Makefile:382: recipe for target 'src' failed

[Glenn Morris]

Glenn Morris wrote:

> Eli Zaretskii wrote:
>
>> I don't know why we keep macuvs.h in the repository; Glenn, can you
>> answer that?
>
> I didn't actually know that we did! :)

I guess it is because there is a circularity:

generating macuvs.h requires an Emacs binary, but (on OS X) compiling an
Emacs binary requires macuvs.h. I imagine it could be changed, with some
sleight of hand - patches welcome.