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
>
#include <limits.h>
#include <stdlib.h>
int main()
{
char resolved_path[PATH_MAX];
if (realpath("///", resolved_path) && (strcmp(resolved_path, "/") == 0)) {
return 0;
} else {
return 1;
}
}
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
