Re: make 3.81rc1 / MSYS
> From: David Ergo <[EMAIL PROTECTED]>
> Cc: bug-make@gnu.org, Xavier Marichal <[EMAIL PROTECTED]>,
> =?ISO-8859-1?Q?S=E9bastien?= Frippiat <[EMAIL PROTECTED]>
> Date: Tue, 07 Mar 2006 09:28:46 +0100
>
> 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;
Okay, will do one of these, thanks.
> '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__
Okay.
> > > 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
And I assume it returns 1 on MSYS, yes?
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: make 3.81rc1 / MSYS
> From: David Ergo <[EMAIL PROTECTED]>
> Cc: bug-make@gnu.org, Xavier Marichal <[EMAIL PROTECTED]>,
> =?ISO-8859-1?Q?S=E9bastien?= Frippiat <[EMAIL PROTECTED]>
> 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.
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: make 3.81rc1 / MSYS
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
#include
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/lis
Re: make 3.81rc1 / MSYS
On Fri, 2006-03-03 at 18:38, Eli Zaretskii wrote:
> > From: David Ergo <[EMAIL PROTECTED]>
> > Date: Tue, 28 Feb 2006 13:08:10 +0100
> > Cc: Xavier Marichal <[EMAIL PROTECTED]>,
> > =?ISO-8859-1?Q?S=E9bastien?= Frippiat <[EMAIL PROTECTED]>
> > I managed to compile a working version of make 3.81rc1 for MSYS but I
> > had do some modifications.
> >
> > first config/config.guess and config/config.sub must be simply patched
> > to support MSYS build system (see config_msys.patch in attachment).
> >
> > sources must be patched (bugs correction) like specified hereunder (also
> > in sources_msys.patch in attachment) :
>
> Thank you for your report. However:
>
> > file job.c, at line 2525 :
> > && strchr (sh_chars_sh, p[1]) == 0)
> > should be :
> > && strchr (sh_chars, p[1]) == 0)
> >
> > file implicit.c, at line 355 :
> > if (!check_lastslash)
> > should be :
> > if (check_lastslash)
> >
> > file make.h, at line 350 :
> > #if defined(HAVE_DOS_PATHS)
> > should be :
> > #if defined(HAVE_DOS_PATHS) && !defined(__MSYS__)
>
> Sorry, it seems I don't understand enough about MSYS-specific issues
> to figure out these problems. sh_chars[] does not exist in the
> WINDOWS32 build; are you saying that you are building the Unix parts
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.
e.g. WINDOWS32 : sh_chars defined at line 2298 and takes its value at
line 2323 or 2325, either sh_chars_sh or sh_chars_dos.
I thinks the code is buggy, it should not assume that sh_chars is
sh_chars_sh.
This is generic not specific to MSYS.
> 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
MSYS accept unix AND msdos paths !
Since I'm not a MSYS developper I cannot provide you with more detailled
explanations.
>
> 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
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)
> my questions above), I hope to be able to craft a patch that fixes the
> MSYS build without screwing others.
>
> > And after executing 'configure', I had to modify config.h manually
> > before executing make (easier for me than correcting the configure
> > script) :
> >
> > to support dos-style paths, changed :
> > /* #undef HAVE_DOS_PATHS */
> > into
> > #define HAVE_DOS_PATHS 1
>
> 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.
>
> > and to use the internal realpath function as a workaround to the buggy
> > msys realpath() function (otherwise the test 'functions/realpath' fails
> > at line 19 about realpath of ///), changed :
> > #define HAVE_REALPATH 1
> > into
> > /* #undef HAVE_REALPATH */
>
> 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.
David
>
> TIA
>
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: make 3.81rc1 / MSYS
> From: David Ergo <[EMAIL PROTECTED]> > Date: Tue, 28 Feb 2006 13:08:10 +0100 > Cc: Xavier Marichal <[EMAIL PROTECTED]>, > =?ISO-8859-1?Q?S=E9bastien?= Frippiat <[EMAIL PROTECTED]> > I managed to compile a working version of make 3.81rc1 for MSYS but I > had do some modifications. > > first config/config.guess and config/config.sub must be simply patched > to support MSYS build system (see config_msys.patch in attachment). > > sources must be patched (bugs correction) like specified hereunder (also > in sources_msys.patch in attachment) : Thank you for your report. However: > file job.c, at line 2525 : > && strchr (sh_chars_sh, p[1]) == 0) > should be : > && strchr (sh_chars, p[1]) == 0) > > file implicit.c, at line 355 : > if (!check_lastslash) > should be : > if (check_lastslash) > > file make.h, at line 350 : > #if defined(HAVE_DOS_PATHS) > should be : > #if defined(HAVE_DOS_PATHS) && !defined(__MSYS__) Sorry, it seems I don't understand enough about MSYS-specific issues to figure out these problems. sh_chars[] does not exist in the WINDOWS32 build; are you saying that you are building the Unix parts 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? 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 my questions above), I hope to be able to craft a patch that fixes the MSYS build without screwing others. > And after executing 'configure', I had to modify config.h manually > before executing make (easier for me than correcting the configure > script) : > > to support dos-style paths, changed : > /* #undef HAVE_DOS_PATHS */ > into > #define HAVE_DOS_PATHS 1 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? > and to use the internal realpath function as a workaround to the buggy > msys realpath() function (otherwise the test 'functions/realpath' fails > at line 19 about realpath of ///), changed : > #define HAVE_REALPATH 1 > into > /* #undef HAVE_REALPATH */ 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? TIA ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
