[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: make 3.81rc1 / MSYS

From: Eli Zaretskii
Subject: Re: make 3.81rc1 / MSYS
Date: Mon, 06 Mar 2006 21:53:12 +0200

> 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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]