Re: make 3.81rc1 / MSYS

[David Ergo]

On Mon, 2006-03-06 at 20:53, Eli Zaretskii wrote:
> > 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.
> 

Ok, now I understand. But for MSYS, as it uses unix code, sh_chars_sh is
not defined and the code doesn't compile, so maybe another solution is
to define it at line 2310 (in the unix case) by something like this :
  ifdef __MSYS__
    char* sh_chars_sh = sh_chars;
  endif
or still another solution, closer to other platforms: at line 2304
define sh_chars_sh instead of sh_chars, and at line 2310, define 
  char* sh_chars = sh_chars_sh;
  
> > > 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.

Forget about what I said... it's probably not correct...
Sorry but I don't known the details, the MSYS FAQ says : "The POSIX
layer used by MSYS is a fork of the 1.3.3 version of Cygwin."
It's not the same as, for example, Cygwin doesn't support DOS-style
paths.

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

'configure' just check for specific platforms to know if DOS paths are
supported.
file 'configure', just change line 8105 :
  #if !defined _WIN32 && !defined __WIN32__ && !defined __MSDOS__ &&
!defined __EMX__
into :
  #if !defined _WIN32 && !defined __WIN32__ && !defined __MSDOS__ &&
!defined __EMX__ && !defined __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.

see simple test file in attachment : 
returns 0 if ok
        1 if buggy

>

test_realpath.c
Description: Text Data