Re: make 3.81rc1 / MSYS

[Eli Zaretskii]

> From: David Ergo <address@hidden>
> Cc: address@hidden, Xavier Marichal <address@hidden>,
>         =?ISO-8859-1?Q?S=E9bastien?= Frippiat <address@hidden>
> Sorry, but as a understand the code, sh_chars_sh is an intermediate
> variable as sh_chars_dos is, and sh_chars is the real variable to use.

That's true.

> I thinks the code is buggy, it should not assume that sh_chars is
> sh_chars_sh.

It doesn't.  It specifically uses sh_chars_sh to refer to characters
special to a Unixy shell, _even_when_ the shell in use is not a Unixy
shell.  That is because many Makefiles are written assuming a Unixy
shell, so they quote special characters with a backslash.  These
backslashes need to be removed even if the shell is cmd.exe.

If you have a specific situation where this specific code causes
trouble, please post the sample Makefile and show how it fails.

> > of the code?  I always thought that MSYS builds are actually MinGW
> > builds, i.e. they use the Windows runtime DLL's, not Cygwin-style
> > Posix runtime libraries.  Am I mistaken?  If so, what is the
> > difference between a Cygwin build of Make and an MSYS build?
> 
> yes, for MSYS we use Unix code
> cygwin build use cygwin dll which is a posix emulation layer
> msys build use msys dll which is a posix native layer

What is a ``posix native layer''?  A runtime can be either native
(i.e. MS-Windows style) or Posix, but not both.

> > In any case, the first two of the 3 changes you suggest above cannot
> > be made as you asked for them, since that would break the other ports
> > of Make for DOS/Windows.  If I understand more about the reasons (see
> 
> If didn't misunderstood the code, these changes are NOT specific to MSYS
> !
> First one : as explained above, sh_chars is sh_chars_sh or sh_chars_dos

Well, I hope I now explained why I think it is right.  I need to see a
real failure to become convinced otherwise and start thinking about a
solution.  If you have such a test case, please show it.

> Second one: the code is buggy even for other builds :
> Line 352 : check_lastslash = strchr (target, '/') == 0;
> So, check_lastslash is true if '/' is not found in target
> Line 354 : /* Didn't find it yet : check for DOS-type directories. */
> So we must check for DOS-type dirs if not found, so line 355 MUST be
>   if (check_lastslash)
> i.e. if ('/' not found)

Yes, you are right, sorry.  I was looking at the wrong line when I
answered your original message.

(Paul, this is the code you changed between beta4 and rc1.)

> > Again, I don't understand this: if configure says that MSYS doesn't
> > have DOS drive letters, why do you need to enable its support?
> 
> MSYS has DOS and UNIX paths :
> c:\msys\bin, c:/msys/bin and /usr/local/bin are all valid paths under
> MSYS.

Then why does the configure scripts says that DOS paths are not
supported on MSYS?  Can you say what test there does the wrong thing
for MSYS?

> > This should be handled by modifying the configure test for realpath.
> > Can you explain what is buggy in the MSYS implementation, so the
> > configure test could be augmented?
> 
> I'm not sure about what is buggy, all I can tell is that if make is
> compiled with MSYS realpath then the test 'functions/realpath' in the
> tests/ subdir fails at line 19 where the test is :
> ifneq ($(realpath ///),/)
>   $(error)
> endif 
> I assume this means that realpath("///") should return "/", but it does
> not.

Can you verify this with a simple test program?  We need to know for
sure to modify the configure script.