From: Markus M. <qw...@ch...> - 2005-12-30 18:40:48
|
Hi, I built make-3.18beta4 (-> ftp://alpha.gnu.org/gnu/make) both under cygwin and under mingw/msys, using basically the same commands inside cygwin's and msys' bash: --- srcroot=/c/usr/src dstroot=/c/mau/out/cyg <------ for cygwin dstroot=/c/mau/out/mss <------ for msys/mingw pkg=make-3.81beta4 src=$srcroot/$pkg dst=$dstroot/$pkg [ -d $dst ] || mkdir $dst && cd $dst $src/configure --enable-case-insensitive-file-system --disable-rpath make CFLAGS='-O3 -s' --- 100% ok for cygwin. 99% ok for msys -- the last build instruction fails: --- gcc -O3 -s -o loadavg.exe loadavg-getloadavg.o loadavg-getloadavg.o:getloadavg.c:(.text+0xd5): undefined reference to `sleep' collect2: ld returned 1 exit status make[2]: *** [loadavg.exe] Error 1 make[2]: Leaving directory `/c/mau/out/mss/make-3.81beta4' --- ... getloadavg.c unconditionally uses POSIX sleep() which comes from <unistd.h> ... but it has #ifdef HAVE_UNISTD_H #include <unistd.h> #endif. And config.h has "#define HAVE_UNISTD_H 1" ... looks like we are missing the corresponding lib during linking. Q: Is this a problem of my msys/mingw installation|usage, or a general problem of current msys/mingw ? Thanks, Markus. |
From: Eli Z. <el...@gn...> - 2005-12-30 18:53:58
|
> From: "Markus Mauhart" <qw...@ch...> > Date: Fri, 30 Dec 2005 19:24:13 +0100 > Cc: min...@li... > > I built make-3.18beta4 (-> ftp://alpha.gnu.org/gnu/make) both under > cygwin and under mingw/msys, using basically the same commands inside > cygwin's and msys' bash: > > --- > srcroot=/c/usr/src > dstroot=/c/mau/out/cyg <------ for cygwin > dstroot=/c/mau/out/mss <------ for msys/mingw > pkg=make-3.81beta4 > src=$srcroot/$pkg > dst=$dstroot/$pkg > [ -d $dst ] || mkdir $dst && cd $dst > $src/configure --enable-case-insensitive-file-system --disable-rpath > make CFLAGS='-O3 -s' > --- > > 100% ok for cygwin. > > 99% ok for msys -- the last build instruction fails: > > --- > gcc -O3 -s -o loadavg.exe loadavg-getloadavg.o > loadavg-getloadavg.o:getloadavg.c:(.text+0xd5): undefined reference to `sleep' > collect2: ld returned 1 exit status > make[2]: *** [loadavg.exe] Error 1 > make[2]: Leaving directory `/c/mau/out/mss/make-3.81beta4' Do I understand correctly that you built the MinGW port of Make by running "./configure; make" from the shell's prompt? If so, then that's not how you should do it. Instead, run the build_w32.bat batch file from cmd.exe, like this: build_w32 gcc (The file README.W32 explains this, I think.) Make sure you delete config.h before you do this, so that build_w32.bat will copy config.h.W32 to config.h and use that. If I build the MinGW port with build_w32.bat, I don't have any problems. |
From: Eli Z. <el...@gn...> - 2005-12-31 08:59:41
|
> From: "Markus Mauhart" <qw...@ch...> > Date: Fri, 30 Dec 2005 23:46:15 +0100 > Cc: min...@li... > > Actually I was just checking the so copied config.h when I thought it > might be a good idea first to check out the config.h computed by > configure@msys-mingw, hence I decided first to run the 'default' > build procedure, with cygwin and with msys/mingw. Well, if config.h.W32 is different from config.h you get by running configure, then please report the discrepancies (with the obvious exceptions of a different ordering). > E.g. I hoped that configure@msys-mingw would suggest > '#define FILE_TIMESTAMP_HI_RES 1' (-> turned out not). Why did you think so? > Another reason for me to preferre buliding via configure@msys-mingw: > I probably have to use the resulting gmake together with msys' sh.exe > to get working "gmake -j" (dual core :-) ... I guess the optimal > partner of msys' sh.exe is gmake built via configure@msys-mingw. Why would you think that? There's nothing in the configure script that tests the shell or any other external utilities, it only probes the compiler, the header files, the libraries, and the OS system calls. > ("gmake -j": I still dont know whether '#3678 make -j unnecessarily > requires an Unix shell' (http://savannah.gnu.org/patch/?func=detailitem&item_id=3678) > will work for current gmake, built with build_w32.bat ...) It will work (or not) in the resulting binary regardless of how it was built, since there's nothing in the configure script that could change the code which rejects -j when a Unixy shell is not available. > Btw, despite the trailing error, configure@msys-mingw DID result > in a working make.exe; nevertheless I'd like to know whether others > can reproduce (or better: help me solve) that error. That error happens when the Makefile produced by the configure script tries to build loadavg.exe, which is a separate program. But you don't need this program, since it is used only for testing the produced Make binary. In fact, I don't even understand why loadavg.exe was built: it seems to be part of check-loadavg target that should be only invoked if you say "make check", which I think you didn't. > Btw 2, many thanks to you, JGrant, Paul and colleagues for putting > so much efforts in gnumake381's builtin windows support ! You're welcome. |
From: J. G. <jg...@jg...> - 2006-01-01 14:58:47
|
On 31/12/05 08:59, Eli Zaretskii wrote: >> From: "Markus Mauhart" <qw...@ch...> <snip> >> Btw, despite the trailing error, configure@msys-mingw DID result >> in a working make.exe; nevertheless I'd like to know whether others >> can reproduce (or better: help me solve) that error. > > That error happens when the Makefile produced by the configure script > tries to build loadavg.exe, which is a separate program. But you > don't need this program, since it is used only for testing the > produced Make binary. In fact, I don't even understand why > loadavg.exe was built: it seems to be part of check-loadavg target > that should be only invoked if you say "make check", which I think you > didn't. MSYS/MinGW "./configure; make" built fine for me, it did not build loadavg.exe. Could you post a full log of your build with this error and the version of MSYS, MinGW please. (I am using MSYS v1.0.10 and MinGW 3.1.0 on Win2K) Kind regards JG |
From: Keith M. <kei...@to...> - 2006-01-03 12:57:07
|
Eli Zaretskii wrote: > Do I understand correctly that you built the MinGW port of Make by > running "./configure; make" from the shell's prompt? If so, then > that's not how you should do it. Instead, run the build_w32.bat batch > file from cmd.exe, like this: > > build_w32 gcc > > (The file README.W32 explains this, I think.) Maybe, but under MSYS, MinGW builds are supposed to be accomplished by using a conventional ./configure && make incantation. This ugly kludge ... > Make sure you delete config.h before you do this, so that > build_w32.bat will copy config.h.W32 to config.h and use that. should not be necessary for MSYS users, IMNSHO. > If I build the MinGW port with build_w32.bat, I don't have any > problems. You will, if you try to run *.bat files under MSYS; they simply do not live there, in any natural sense; (however, start cmd.exe //c build_w32 ... might work). Regards, Keith. |
From: Eli Z. <el...@gn...> - 2006-01-03 18:51:32
|
> Cc: mak...@gn..., "Markus Mauhart" <qw...@ch...>, > Eli Zaretskii <el...@gn...> > From: Keith MARSHALL <kei...@to...> > Date: Tue, 3 Jan 2006 12:51:24 +0000 > > Eli Zaretskii wrote: > > Do I understand correctly that you built the MinGW port of Make by > > running "./configure; make" from the shell's prompt? If so, then > > that's not how you should do it. Instead, run the build_w32.bat batch > > file from cmd.exe, like this: > > > > build_w32 gcc > > > > (The file README.W32 explains this, I think.) > > Maybe, but under MSYS, MinGW builds are supposed to be accomplished > by using a conventional > > ./configure && make I don't know about ``supposed to''; AFAIK, GNU Make didn't support MinGW builds out of the box until such a support was added in 3.81beta3. Besides the configury stuff, there were quite a few nasty warnings from the compiler, and Make would completely go awry if you interrupted it with a Ctrl-C. Not to mention the fact that there was not a word in any README in the tarball that would suggest how to build a MinGW port of Make. The Windows-related documentation mentioned MSVC and it alone. Besides, I think a tool so basic as Make, which is a prerequisite to building other tools, should have a simple build procedure that doesn't require a working Make, a port of Bash, and other utilities that are hard to find on Windows. Even Unix has build.sh. > This ugly kludge ... > > > Make sure you delete config.h before you do this, so that > > build_w32.bat will copy config.h.W32 to config.h and use that. > > should not be necessary for MSYS users, IMNSHO. It is not necessary if you use build_w32.bat, either. > > If I build the MinGW port with build_w32.bat, I don't have any > > problems. > > You will, if you try to run *.bat files under MSYS; they simply do > not live there, in any natural sense Which is IMNSHO a bug in MSYS. (Compare that with the DJGPP port of Bash, where batch files would run with no problems at all.) > (however, > > start cmd.exe //c build_w32 ... > > might work). What's wrong with a simpler "cmd.exe /c build_w32"? And what's with the doubling of the slash in "//c"? |
From: Keith M. <kei...@to...> - 2006-01-04 10:57:05
|
Eli Zaretskii wrote, quoting me: >> Maybe, but under MSYS, MinGW builds are supposed to be accomplished >> by using a conventional >>=20 >> ./configure && make > > I don't know about ``supposed to''; AFAIK, GNU Make didn't support > MinGW builds out of the box until such a support was added in > 3.81beta3. ... Yes, `supposed to'. This is the very essence of the raison d'=EAtre for MSYS -- to provide a minimal GNU/POSIX-like environment, which when it is coupled with the MinGW port of GCC, permits the building and installation of GNU Coding Standards conformant applications using the conventional `./configure && make && make install' mantra. > Besides, I think a tool so basic as Make, which is a prerequisite to > building other tools, should have a simple build procedure that > doesn't require a working Make, a port of Bash, and other utilities > that are hard to find on Windows. Even Unix has build.sh. MSYS provides those so called hard to find tools, in one handy self extracting package: http://prdownloads.sourceforge.net/mingw/MSYS-1.0.10.exe?download Add MinGW to that (either the last stable release): http://prdownloads.sourceforge.net/mingw/MinGW-3.1.0-1.exe?download (or the latest proposed development release): http://prdownloads.sourceforge.net/mingw/MinGW-5.0.0.exe?download and you should have everything required for GNU Coding Standards conformance, in a build environment. However, I understand your point about the `chicken-and-egg' dilemma, on the horns of which make may be found; perhaps build.sh should also work with MSYS, but I don't have the time to explore this possibility at present. >>> If I build the MinGW port with build=5Fw32.bat, I don't have any >>> problems. >> >> You will, if you try to run *.bat files under MSYS; they simply do >> not live there, in any natural sense > > Which is IMNSHO a bug in MSYS. (Compare that with the DJGPP port > of Bash, where batch files would run with no problems at all.) Well, to express a `not so humble opinion' from such a clear position of ill informed ignorance is, IMHO, simply a statement of arrogant stupidity. This is NOT a bug in MSYS. Does bash on GNU/Linux, or on any other POSIX platform process Windows/MS-DOS format *.bat scripts? No? Then why on earth would you expect it to do so on MSYS? The ability to do so is clearly beyond the scope of its stated design objectives, contrary to the case with DJGPP. >> (however, >>=20 >> start cmd.exe //c build=5Fw32 ... >>=20 >> might work). > > What's wrong with a simpler "cmd.exe /c build=5Fw32"? Yes, even `cmd //c build=5Fw32 ...' might also work; the `start' variant is used to run the cmd.exe task as a background process. > And what's with the doubling of the slash in "//c"? Clearly stated in MSYS documentation, if you took the trouble to research the facts, before leaping into print to show off your ignorance; the doubled `/' is required to prevent MSYS from translating `/c' to `c:/', before handing it off as an argument to cmd.exe. Regards, Keith. |
From: Eli Z. <el...@gn...> - 2006-01-04 17:27:53
|
> Cc: Keith MARSHALL <kei...@to...>, mak...@gn..., > min...@li..., qw...@ch... > From: Keith MARSHALL <kei...@to...> > Date: Wed, 4 Jan 2006 10:50:52 +0000 > > >> You will, if you try to run *.bat files under MSYS; they simply do > >> not live there, in any natural sense > > > > Which is IMNSHO a bug in MSYS. (Compare that with the DJGPP port > > of Bash, where batch files would run with no problems at all.) > > Well, to express a `not so humble opinion' from such a clear position > of ill informed ignorance is, IMHO, simply a statement of arrogant > stupidity. I don't think I qualify as ignorant about porting GNU software to DOS and Windows. As for stupidity--that's something for others to decide. However, to keep the argument out of ad hominem domain, perhaps you should point out where's the stupidity without actually using the label as offending as that. > Does bash on GNU/Linux, or on any other POSIX platform process > Windows/MS-DOS format *.bat scripts? No? Then why on earth would > you expect it to do so on MSYS? Because MSYS runs on Windows, where there's a known interpreter for batch files, and because there's absolutely no reason for the MSYS port of Bash to be gratuitously harsh to Windows users, which expect batch files to ``just work''. > The ability to do so is clearly beyond the scope of its stated > design objectives If MSYS design objectives are limited to running Unix scripts, then so be it; but I think it's a gratuitous limitation, which can be easily lifted. > Yes, even `cmd //c build_w32 ...' might also work; the `start' variant > is used to run the cmd.exe task as a background process. > > > And what's with the doubling of the slash in "//c"? > > Clearly stated in MSYS documentation, if you took the trouble to > research the facts, before leaping into print to show off your > ignorance; the doubled `/' is required to prevent MSYS from > translating `/c' to `c:/', before handing it off as an argument > to cmd.exe. Another bug/misfeature, IMNSHO: MSYS has no business second-guessing the user's intent and assuming that "/c" must be a file name. |
From: Luke D. <cod...@ho...> - 2006-01-05 15:06:31
|
----- Original Message ----- From: "Eli Zaretskii" <el...@gn...> To: "Keith MARSHALL" <kei...@to...> Cc: <mak...@gn...>; <min...@li...>; <qw...@ch...> Sent: Thursday, January 05, 2006 1:14 AM Subject: Re: [Mingw-users] Re: make'ing make-3.18beta4 under mingw/msys - "undefined reference to `sleep'" >> Cc: Keith MARSHALL <kei...@to...>, mak...@gn..., >> min...@li..., qw...@ch... >> From: Keith MARSHALL <kei...@to...> >> Date: Wed, 4 Jan 2006 10:50:52 +0000 >> >> >> You will, if you try to run *.bat files under MSYS; they simply do >> >> not live there, in any natural sense >> > >> > Which is IMNSHO a bug in MSYS. (Compare that with the DJGPP port >> > of Bash, where batch files would run with no problems at all.) >> >> Well, to express a `not so humble opinion' from such a clear position >> of ill informed ignorance is, IMHO, simply a statement of arrogant >> stupidity. > > I don't think I qualify as ignorant about porting GNU software to DOS > and Windows. As for stupidity--that's something for others to decide. > However, to keep the argument out of ad hominem domain, perhaps you > should point out where's the stupidity without actually using the > label as offending as that. FWIW I agree that your comments were arrogant but that Keith's reply was unnecessarily harsh. [snip batch file stuff] >> Yes, even `cmd //c build_w32 ...' might also work; the `start' variant >> is used to run the cmd.exe task as a background process. >> >> > And what's with the doubling of the slash in "//c"? >> >> Clearly stated in MSYS documentation, if you took the trouble to >> research the facts, before leaping into print to show off your >> ignorance; the doubled `/' is required to prevent MSYS from >> translating `/c' to `c:/', before handing it off as an argument >> to cmd.exe. > > Another bug/misfeature, IMNSHO: MSYS has no business second-guessing > the user's intent and assuming that "/c" must be a file name. Again this is the whole purpose of MSYS: it translates paths on the command line from POSIX to Windows so that 'configure' scripts and other POSIX tools can interoperate with the MinGW compiler and other native Windows programs. MSYS is useful to a lot of people (200,000+ downloads of the current version) but if you don't see the point then that is too bad, but this discussion doesn't seem to be going anywhere useful or constructive. Luke |
From: Eli Z. <el...@gn...> - 2006-01-05 17:05:28
|
> From: "Luke Dunstan" <cod...@ho...> > Cc: <el...@gn...> > Date: Thu, 5 Jan 2006 23:06:28 +0800 > > FWIW I agree that your comments were arrogant Since when expressing an opinion that something is a bug counts as arrogant? > Again this is the whole purpose of MSYS: it translates paths on the command > line from POSIX to Windows so that 'configure' scripts and other POSIX tools > can interoperate with the MinGW compiler and other native Windows programs. I know the reason for that, believe me. I'm not as ignorant as some people try to describe me. And yet I think that this translation is a misfeature, because a general-purpose code cannot possibly know what the user meant by "/c". (For the record, I needed to make a non-trivial change in Emacs a couple of weeks ago to work around this ``feature'' which caused the MSYS shell to pass a bad file name to Emacs during the build process. See http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-12/msg00238.html and the rest of that thread, for the gory details.) > MSYS is useful to a lot of people (200,000+ downloads of the current > version) MSYS being useful doesn't mean that it cannot be improved and become even more useful. |
From: Keith M. <kei...@to...> - 2006-01-06 15:23:40
|
Eli Zaretskii wrote, quoting Luke Dunstan: >> FWIW I agree that your comments were arrogant > > Since when expressing an opinion that something is a bug counts as > arrogant? The arrogance lay not in the expression of the opinion per se, but in the manner of its expression; if you persistently indicate that your opinions are "not so humble" -- as you do -- that is, by definition, downright arrogance. >> Again this is the whole purpose of MSYS: it translates paths on the >> command line from POSIX to Windows so that 'configure' scripts and >> other POSIX tools can interoperate with the MinGW compiler and other >> native Windows programs. > > I know the reason for that, believe me. Really? The evidence of your previous comments would suggest that the opposite is, in fact, the case. > I'm not as ignorant as some people try to describe me. By "some people", I presume that you are referring to me. The name of Eli Zaretskii carries a considerable reputation in the free software world, and I have no doubt that you are actually an extremely accomplished software engineer; no, I do not believe that you actually are ignorant. However, you do display a certain ignorance of MSYS, and yet you still persist in arrogantly expressing so called expert opinion on it. You asked previously, why I might consider you to be stupid. Well, the short answer is that I don't; I honestly do believe that you are actually very clever; but even the most clever people occassionally do stupid things. Please consider the following:-- a) The true expert offers opinion with humility, and allows the quality of his work to bear testament to his expertise. b) The true expert will decline to offer opinion on subjects, about which he does not believe himself to be adequately informed. Given the apparently uninformed nature of your arrogantly expressed opinions on MSYS, you expose yourself to the potential criticism that you are a pompous ass, consequentially damaging your reputation; it is exposing yourself to such criticism, I would suggest, that might be construed as stupid. > And yet I think that this translation is a misfeature, because a > general-purpose code cannot possibly know what the user meant by "/c". While it may not be immediately obvious in the current context, when viewed in the full context of your earlier remarks on the same subject, this statement is so patently ridiculous, that it simply beggars belief. Of course the user's intent is perfectly clear, because he himself knows that "/c" refers to the MSYS mount point, where the Windows "C:" drive is attached to the file system, as it is represented in the POSIX-like model that MSYS uses at the command interpreter level. He also knows, because he read it in the README file he was shown, when he installed MSYS, that if he needs to pass a "/c" option flag to a native Windows application, then he must enter that, on the command line, in the form "//c". (Of course, there will be users who neglect to look at README files; to them, I offer no apology, for they are victims of their own folly). Regards, Keith. |
From: Eli Z. <el...@gn...> - 2006-01-06 17:20:48
|
> Cc: "Luke Dunstan" <cod...@ho...>, > min...@li... > From: Keith MARSHALL <kei...@to...> > Date: Fri, 6 Jan 2006 15:10:24 +0000 > > Eli Zaretskii wrote, quoting Luke Dunstan: > >> FWIW I agree that your comments were arrogant > > > > Since when expressing an opinion that something is a bug counts as > > arrogant? > > The arrogance lay not in the expression of the opinion per se, but in > the manner of its expression; if you persistently indicate that your > opinions are "not so humble" -- as you do -- that is, by definition, > downright arrogance. Ah, okay, so an opinion is either humble, if it's explicitly qualified as such, or arrogant otherwise? Don't you think your standards are a tad too touchy and unrealistic? > > I'm not as ignorant as some people try to describe me. > > By "some people", I presume that you are referring to me. The name > of Eli Zaretskii carries a considerable reputation in the free software > world, and I have no doubt that you are actually an extremely accomplished > software engineer; no, I do not believe that you actually are ignorant. > However, you do display a certain ignorance of MSYS, and yet you still > persist in arrogantly expressing so called expert opinion on it. After working in the field of porting GNU and Unix software to DOS and Windows for more than 15 years (and counting), I think I can offer expert opinion even if I didn't have the chance of reading the MSYS internals. One can judge design and user interface even without a deep knowledge of the code, just by looking at the consequences. And having myself bumped into similar issues more than twice, I think I know something about possible alternative solutions, and merits and demerits of each one of them. But even if I did not know anything about these matters, I think you should have embraced a layman's opinion. Naive newbies sometimes tell us something that we professionals fail to see, I'm sure you know that. I'm astonished that people here are requested to be experts in the details before they can comment on the results. > Given the apparently uninformed nature of your arrogantly expressed > opinions on MSYS, you expose yourself to the potential criticism that > you are a pompous ass, consequentially damaging your reputation; it > is exposing yourself to such criticism, I would suggest, that might > be construed as stupid. Look, what I wrote was supposed to be a criticism of how MSYS resolved the issues of running Posix software on MS-Windows. I assumed that, as customary among professionals in general and in the Free Software community in particular, criticism is accepted as aimed at improving the quality of your work. I expected that MSYS maintainers will want to ask what I suggest as alternative solutions to the underlying issues,and might benefit from my suggestions. But if the MSYS community can offer nothing in response except harsh, uncivilized language and NIH-style defensiveness, then I'm sorry I've ever spoken, because a community that does not embrace outside criticism does not deserve the effort of reporting a bug! > > And yet I think that this translation is a misfeature, because a > > general-purpose code cannot possibly know what the user meant by "/c". > > While it may not be immediately obvious in the current context, when > viewed in the full context of your earlier remarks on the same subject, > this statement is so patently ridiculous, that it simply beggars belief. > Of course the user's intent is perfectly clear, because he himself knows > that "/c" refers to the MSYS mount point, where the Windows "C:" drive is > attached to the file system, as it is represented in the POSIX-like model > that MSYS uses at the command interpreter level. He also knows, because > he read it in the README file he was shown, when he installed MSYS, that > if he needs to pass a "/c" option flag to a native Windows application, > then he must enter that, on the command line, in the form "//c". (Of > course, there will be users who neglect to look at README files; to > them, I offer no apology, for they are victims of their own folly). That is an extremely narrow view, both of your audience and the area of application of your tools. First, you assume that users always read all the documentation, where in practice they expect things that are obvious to them to ``just work''. Thus, failure to behave according to user expectations is an annoyance, even if it is well documented. Second, you assume that the users write all commands themselves. In practice, it is much more probable that the offending command came from some script or Makefile whose author knew nothing about this MSYS limitation, and in fact assumed that no development environment and no ported utility will ever break something as basic as program invocation by second-guessing the meaning of the command-line arguments. The case of the NTEmacs build system, which I mentioned earlier in this thread, is an excellent example: MSYS was the only environment that broke the build, because no one could imagine that a command-line argument will not be passed to a program in the same form as it appeared in the Makefile. And third, while it might be reasonable to assume that, in the context of _file_names_ "/c" refers to a mount point of drive C:, no one said that every command-line argument is always a file name. For example, a Sed command line can quite legitimately say something like this: sed -e /c/s/foo/bar/g I think it's clear that, although this looks like a file name, it really isn't, and treating it as a file name that can be converted to C:\s\foo\bar will produce utterly unexpected results. I could continue telling you why I think this /c treatment is not a very good design. But since I will most probably get nothing in response but more of ad hominem attacks, why should I even bother? |
From: Eli Z. <el...@gn...> - 2006-01-06 20:03:43
|
> From: "Luke Dunstan" <ldu...@ii...> > Cc: <min...@li...> > Date: Sat, 7 Jan 2006 02:03:44 +0800 > > The simple fact is that you are the only person I've seen on this list claim > that the whole concept of MSYS is a bug. When other people see behaviour > that they feel is a bug, they first ask what is happening, whether it is a > bug, and if not, why it is designed that way. I didn't ask that because I think already know the answers to those questions. > I realise that you only posted due to a thread cross-posted to > another list, but I doubt that is the whole reason. What other reasons could there be? I don't have any hidden agenda. The OP cross-posted to the MinGW list, and I respected his decision that this might be of interest to you here. > Now that we all understand your opinion that the argument translation is a > bug, what would you propose as an alternative way to accomplish the goals of > MSYS, keeping in mind the limitations of Cygwin that led to the creation of > MSYS? AFAIK, the /c translation and the whole mount point feature was introduced to deal with the assumption in many Unix shell scripts and programs that an absolute file name always starts with a slash. (If this is not the reason in MSYS, then please tell what _is_ the reason.) If this is indeed so, then I simply don't see any reasons to stick to the /foo/bar syntax nowadays; the days when that was required are long gone. GNU Autoconf, libtool, and the rest of configury tools already support Windows-style d:/foo/bar absolute file name; if there are dark corners where this support is still not complete, people should report that as bugs, and my experience is that package maintainers generally accept patches to fix that. Elsewhere, outside the shell domain, Windows file-related system calls have no problems doing TRT with forward slashes, so d:/foo/bar instead of d:\foo\bar is okay there, too. And many (most?) GNU packages already include code to support d:/foo/bar file names (witness the macros such as IS_ABSOLUTE and its ilk). Again, where this support is insufficient, I urge people to report it as bugs and submit patches to fix them. The single most important exception from this widespread support for d:/foo/bar syntax is stock Windows shells, cmd.exe and command.com. (cmd.exe will accept forward slashes if the file name is quoted, but let's forget about this for the moment.) So when MSYS invokes a program through cmd.exe or command.com, it should convert the slashes to backslashes in the first argument passed to the shell, which is a path to the program or batch file which the shell should invoke; the rest of the arguments should not be modified at all, since they will be processed by the invoked program, not by the shell itself. In all other cases, no conversion of command-line arguments should take place. If there are situations where this method will cause trouble, please tell what they are, and let's see how they can be resolved. |
From: Earnie B. <ea...@us...> - 2006-01-07 11:17:23
|
On Fri, 06 Jan 2006 22:03:33 +0200, Eli Zaretskii wrote > > > Now that we all understand your opinion that the argument translation is a > > bug, what would you propose as an alternative way to accomplish the goals of > > MSYS, keeping in mind the limitations of Cygwin that led to the creation of > > MSYS? > > AFAIK, the /c translation and the whole mount point feature was > introduced to deal with the assumption in many Unix shell scripts and > programs that an absolute file name always starts with a slash. (If > this is not the reason in MSYS, then please tell what _is_ the > reason.) If this is indeed so, then I simply don't see any reasons > to stick to the /foo/bar syntax nowadays; the days when that was required > are long gone. > Those days are still around for those packages that haven't upgraded to newer versions of autotools. MSYS itself will handle c:/ as will as /c. I have a patch in the works, if I ever find the time again, to change the value of the environment variable prefix to its windows native representation. We recommend that people use --prefix="`cd /mingw && pwd -W`" which will set the native windows value of the prefix variable for make to use. <example> $ ls -l c:/ ls: c:/hiberfil.sys: Permission denied ls: c:/pagefile.sys: Permission denied total 147 drwxr-xr-x 8 Earnie B Administ 0 Jun 29 2005 Documents and Settings -rw-r--r-- 1 Earnie B Administ 95 Dec 15 04:25 DownloadLog.txt drwxr-xr-x 2 Earnie B Administ 0 Aug 7 22:24 GameRival drwxr-xr-x 7 Earnie B Administ 0 Feb 4 2005 I386 -r--r--r-- 1 Earnie B Administ 0 Jul 4 2005 IO.SYS -r--r--r-- 1 Earnie B Administ 0 Jul 4 2005 MSDOS.SYS dr-xr-xr-x 3 Earnie B Administ 0 Feb 4 2005 MSOCache drwxr-xr-x 2 Earnie B Administ 0 Dec 15 04:12 My Download Files drwxr-xr-x 34 Earnie B Administ 0 Dec 15 04:12 My Games drwxr-xr-x 2 Earnie B Administ 0 Dec 24 23:05 Pictures dr-xr-xr-x 51 Earnie B Administ 0 Jan 7 00:18 Program Files drwxr-xr-x 6 Earnie B Administ 0 May 25 2005 RECYCLER drwxr-xr-x 3 Earnie B Administ 0 Aug 26 20:52 RealData drwxr-xr-x 41 Earnie B Administ 0 Feb 4 2005 SWSETUP drwxr-xr-x 6 Earnie B Administ 0 May 12 2005 SYSTEM.SAV drwxr-xr-x 0 Earnie B Administ 0 May 12 2005 System Volume Information drwxr-xr-x 10 Earnie B Administ 0 Jan 3 19:53 Temp drwxr-xr-x 95 Earnie B Administ 0 Jan 6 21:08 WINDOWS -r--r--r-- 1 Earnie B Administ 211 May 12 2005 boot.ini drwxr-xr-x 3 Earnie B Administ 0 May 12 2005 hp -r-xr-xr-x 1 Earnie B Administ 47564 Aug 4 2004 ntdetect.com -r--r--r-- 1 Earnie B Administ 250032 Aug 4 2004 ntldr drwxr-xr-x 27 Earnie B Administ 0 Jan 3 19:52 opt drwxr-xr-x 3 Earnie B Administ 0 Jun 12 2005 webdev drwxr-xr-x 6 Earnie B Administ 0 Dec 26 14:33 www </example> > GNU Autoconf, libtool, and the rest of configury tools already > support Windows-style d:/foo/bar absolute file name; if there are > dark corners where this support is still not complete, people should > report that as bugs, and my experience is that package maintainers > generally accept patches to fix that. > I agree. > Elsewhere, outside the shell domain, Windows file-related system > calls have no problems doing TRT with forward slashes, so d:/foo/bar > instead of d:\foo\bar is okay there, too. And many (most?) GNU packages > already include code to support d:/foo/bar file names (witness the > macros such as IS_ABSOLUTE and its ilk). Again, where this support > is insufficient, I urge people to report it as bugs and submit > patches to fix them. > MSYS takes advantage of that feature. Spawning to cmd.exe or command.com though requires a translation to the backslash form for the spawned process path. > The single most important exception from this widespread support for > d:/foo/bar syntax is stock Windows shells, cmd.exe and command.com. > (cmd.exe will accept forward slashes if the file name is quoted, but > let's forget about this for the moment.) So when MSYS invokes a > program through cmd.exe or command.com, it should convert the slashes > to backslashes in the first argument passed to the shell, which is a > path to the program or batch file which the shell should invoke; the > rest of the arguments should not be modified at all, since they will > be processed by the invoked program, not by the shell itself. In all > other cases, no conversion of command-line arguments should take > place. > Which I see you state here. The MSYS user would be angry with me if I didn't convert the paths. As a matter of fact, that is one of the reasons I forked Cygwin to begin with. The translation of paths from POSIX representation to WINDOWS paths (the translation output is with forward slash, ie: c:/foo/bar) is a must when spawning the native program for MSYS. > If there are situations where this method will cause trouble, please > tell what they are, and let's see how they can be resolved. > One of the things MSYS provides is a mapping of the windows filesystem to a POSIX one. So if I want /usr/local on drive e:/ while /usr is on drive c: I can easily work in familiar style. In /etc/fstab I would enter a line ``e:/mnt/usr/local /usr/local'' and now my data is on two different drives without any further need to specify it in my commands. Earnie |
From: Keith M. <kei...@us...> - 2006-01-08 19:03:45
|
On Saturday 07 January 2006 11:17 am, you wrote: > MSYS itself will handle c:/ as will as /c. I have a > patch in the works, if I ever find the time again, to change the value of > the environment variable prefix to its windows native representation. We > recommend that people use --prefix="`cd /mingw && pwd -W`" which will set > the native windows value of the prefix variable for make to use. I've never been enthusiastic about that patch. The desired effect can be achieved by placing either ac_default_prefix=`cd /mingw && pwd -W` or ac_default_prefix=`cd /usr/local && pwd -W` (depending on your preferred default installation path), in /usr/local/share/config.site, as described by Stepan Kasal, here: http://lists.gnu.org/archive/html/autoconf/2005-04/msg00001.html I've been using this solution with complete success, on stock msys-1.0.10, for several months now -- in fact since we had the original discussion on this topic. Why smack the runtime environment, to achieve a particular effect with just one tool, and potentially create problems elsewhere, when the tool in question already provides a standard mechanism for adapting its own behaviour to deliver the required effect anyway? BTW, you shouldn't use backtick shell substitution within quotes, as in the --prefix example cited. This usage isn't portable, and there was an incidence of bizarre command failure resulting from this, reported on the mingw-msys list, as recently as last week. See the links: http://sourceforge.net/mailarchive/message.php?msg_id=14306922 http://sourceforge.net/mailarchive/message.php?msg_id=14354463 for the original problem statement, and my subsequent follow up. Regards, Keith. |
From: Eli Z. <el...@gn...> - 2006-01-07 13:10:22
|
> From: "Earnie Boyd" <ea...@us...> > Cc: Eli Zaretskii <el...@gn...> > Date: Sat, 7 Jan 2006 06:17:16 -0500 > > > I simply don't see any reasons to stick to the /foo/bar syntax > > nowadays; the days when that was required are long gone. > > Those days are still around for those packages that haven't upgraded to newer > versions of autotools. Which packages are those? How many such packages do we know about? > MSYS itself will handle c:/ as will as /c. I had no doubt about this, so let's not be side-tracked into discussing this. > Spawning to cmd.exe or command.com though requires a translation to > the backslash form for the spawned process path. I don't think I understand what you mean by ``the spawned process path''. Do you mean the value of PATH that is passed to the child process? If so, then I agree that it needs its slashes be mirrored to backslashes and colons turned to semi-colons. But this has nothing to do with the issue I was talking about: I was talking about messing with _command_line_arguments_. > > The single most important exception from this widespread support for > > d:/foo/bar syntax is stock Windows shells, cmd.exe and command.com. > > (cmd.exe will accept forward slashes if the file name is quoted, but > > let's forget about this for the moment.) So when MSYS invokes a > > program through cmd.exe or command.com, it should convert the slashes > > to backslashes in the first argument passed to the shell, which is a > > path to the program or batch file which the shell should invoke; the > > rest of the arguments should not be modified at all, since they will > > be processed by the invoked program, not by the shell itself. In all > > other cases, no conversion of command-line arguments should take > > place. > > > > Which I see you state here. Sorry, I don't understand what you mean by this. Please explain. > The MSYS user would be angry with me if I didn't convert the paths. Again, if you are talking about PATH, that's another issue. > As a matter of fact, that is one of the reasons I forked > Cygwin to begin with. The translation of paths from POSIX representation to > WINDOWS paths (the translation output is with forward slash, ie: c:/foo/bar) > is a must when spawning the native program for MSYS. I am arguing that you don't need the Posix /c/foo/bar representation at all, you could use c:/foo/bar throughout. And for the command-line arguments, you could simply leave c:/foo/bar file names alone. > One of the things MSYS provides is a mapping of the windows filesystem to a > POSIX one. So if I want /usr/local on drive e:/ while /usr is on drive c: I > can easily work in familiar style. If this mapping is the main reason for trying to interpret command line arguments (instead of simply passing them verbatim to subprograms), then I'd say it's better to toss the mapping feature. When the ported binaries are built, you could configure them with a non-default prefix so that they won't look for files in /usr/local, but in another directory, whose name is given in the d:/foo/bar format. |
From: Earnie B. <ea...@us...> - 2006-01-07 22:25:50
|
On Sat, 07 Jan 2006 15:08:49 +0200, Eli Zaretskii wrote > > From: "Earnie Boyd" <ea...@us...> > > Cc: Eli Zaretskii <el...@gn...> > > Date: Sat, 7 Jan 2006 06:17:16 -0500 > > > > > I simply don't see any reasons to stick to the /foo/bar syntax > > > nowadays; the days when that was required are long gone. > > > > Those days are still around for those packages that haven't upgraded to newer > > versions of autotools. > > Which packages are those? How many such packages do we know about? > I'm not sure of any specific one at the moment. > > MSYS itself will handle c:/ as will as /c. > > I had no doubt about this, so let's not be side-tracked into > discussing this. > > > Spawning to cmd.exe or command.com though requires a translation to > > the backslash form for the spawned process path. > > I don't think I understand what you mean by ``the spawned process > path''. Do you mean the value of PATH that is passed to the child > process? If so, then I agree that it needs its slashes be mirrored > to backslashes and colons turned to semi-colons. But this has > nothing to do with the issue I was talking about: I was talking > about messing with _command_line_arguments_. > Yes, the path of the executable the process will execute. The command line arguments at times will have paths. The first release of MSYS didn't modify the command line. But as more and more packages were being built using MSYS it became obvious that I needed to parse through the command line arguments to help resolve the conversion issue. > > > The single most important exception from this widespread support for > > > d:/foo/bar syntax is stock Windows shells, cmd.exe and command.com. > > > (cmd.exe will accept forward slashes if the file name is quoted, but > > > let's forget about this for the moment.) So when MSYS invokes a > > > program through cmd.exe or command.com, it should convert the slashes > > > to backslashes in the first argument passed to the shell, which is a > > > path to the program or batch file which the shell should invoke; the > > > rest of the arguments should not be modified at all, since they will > > > be processed by the invoked program, not by the shell itself. In all > > > other cases, no conversion of command-line arguments should take > > > place. > > > > > > > Which I see you state here. > > Sorry, I don't understand what you mean by this. Please explain. > You had stated in your later paragraph what I had just stated in response to your previous paragraph. > > The MSYS user would be angry with me if I didn't convert the paths. > > Again, if you are talking about PATH, that's another issue. > This relates to any and all that are converted; environment or command line. > > As a matter of fact, that is one of the reasons I forked > > Cygwin to begin with. The translation of paths from POSIX representation to > > WINDOWS paths (the translation output is with forward slash, ie: c:/foo/bar) > > is a must when spawning the native program for MSYS. > > I am arguing that you don't need the Posix /c/foo/bar representation > at all, you could use c:/foo/bar throughout. And for the command- > line arguments, you could simply leave c:/foo/bar file names alone. > Yes I could but not for every occurrence. If a command line argument needs a path list the in POSIX style 'c:/foo/bar:c:/foo/baz' doesn't parse well. > > One of the things MSYS provides is a mapping of the windows filesystem to a > > POSIX one. So if I want /usr/local on drive e:/ while /usr is on drive c: I > > can easily work in familiar style. > > If this mapping is the main reason for trying to interpret command > line arguments (instead of simply passing them verbatim to > subprograms), then I'd say it's better to toss the mapping feature. > When the ported binaries are built, you could configure them with a > non-default prefix so that they won't look for files in /usr/local, > but in another directory, whose name is given in the d:/foo/bar > format. The main reason for the mapping is that it makes using an existing script easier without having to modify it to fit the windows file system path. Earnie |
From: Eli Z. <el...@gn...> - 2006-01-08 04:46:37
|
> From: "Earnie Boyd" <ea...@us...> > Cc: min...@li..., ldu...@ii... > Date: Sat, 7 Jan 2006 17:25:39 -0500 > > Yes, the path of the executable the process will execute. I still don't think I get what you mean. Is it what the program gets as its argv[0]? If so, there's no special need to do anything with that, as the OS provides the right file name there anyway. > The command line > arguments at times will have paths. The first release of MSYS didn't modify > the command line. But as more and more packages were being built using MSYS > it became obvious that I needed to parse through the command line arguments to > help resolve the conversion issue. Well, I asked to describe those issues, because in my experience they are usually bugs in the scripts (that are mostly fixed these days in GNU configury stuff). As Windows filesystem layer supports forward slashes, there's no need to convert anything. > > I am arguing that you don't need the Posix /c/foo/bar representation > > at all, you could use c:/foo/bar throughout. And for the command- > > line arguments, you could simply leave c:/foo/bar file names alone. > > Yes I could but not for every occurrence. If a command line argument needs a > path list the in POSIX style 'c:/foo/bar:c:/foo/baz' doesn't parse well. A directory list that uses colons should not appear verbatim on the command line in a script; that's a bug. The script should use a system-dependent character, which on Windows should be computed as semi-colon. Again, in those rare cases where directory lists are passed via command line args, this issue is mostly fixed in GNU software. > > > One of the things MSYS provides is a mapping of the windows filesystem to a > > > POSIX one. So if I want /usr/local on drive e:/ while /usr is on drive c: I > > > can easily work in familiar style. > > > > If this mapping is the main reason for trying to interpret command > > line arguments (instead of simply passing them verbatim to > > subprograms), then I'd say it's better to toss the mapping feature. > > When the ported binaries are built, you could configure them with a > > non-default prefix so that they won't look for files in /usr/local, > > but in another directory, whose name is given in the d:/foo/bar > > format. > > The main reason for the mapping is that it makes using an existing script > easier without having to modify it to fit the windows file system path. Well, it should be clear by now that I think this mapping is a design mistake (whose origins are in Cygwin). Trying to transparently support /usr/local and its ilk brings more problems than it solves. It is easier to modify the scripts, and, in fact, most of them are already modified to not require the mapping. |
From: Earnie B. <ea...@us...> - 2006-01-08 13:46:19
|
----- Message from el...@gn... --------- >> From: "Earnie Boyd" <ea...@us...> >> Cc: min...@li..., ldu...@ii... >> Date: Sat, 7 Jan 2006 17:25:39 -0500 >> >> Yes, the path of the executable the process will execute. > > I still don't think I get what you mean. Is it what the program gets > as its argv[0]? If so, there's no special need to do anything with > that, as the OS provides the right file name there anyway. > Yes. I'm talking about the program that creates the value for argv[0]. It needs to ensure the use of back slash and not forward slash as cmd.exe will not understand it and think it's an option switch. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Earnie B. <ea...@us...> - 2006-01-07 11:24:53
|
On Fri, 06 Jan 2006 19:20:06 +0200, Eli Zaretskii wrote > > And third, while it might be reasonable to assume that, in the > context of _file_names_ "/c" refers to a mount point of drive C:, no > one said that every command-line argument is always a file name. > For example, a Sed command line can quite legitimately say > something like this: > It became /c because I didn't like /cygdrive/c. > sed -e /c/s/foo/bar/g > There are more ways to write the inline script than there are ways to deal with UNIX to DOS/WINDOWS translations. MSYS isn't perfect, its goal was and still is simply to provide a tool with a minimum number of executables to be able to execute a typical configure && make to allow maintainers a common mechanism for building packages between UNIX and Windows. There are some major sized packages, I'm thinking in particular of ACE/TAO, using MSYS and MinGW to build the windows based versions of their applications. > I think it's clear that, although this looks like a file name, it > really isn't, and treating it as a file name that can be converted to > C:\s\foo\bar will produce utterly unexpected results. > Well, actually, your example wouldn't change /c/s/foo/bar/g to c:\s\foo\bar because sed uses the MSYS runtime. Only those programs that use the MSVCRT runtime have the paths translated before spawning the process. > I could continue telling you why I think this /c treatment is not a > very good design. But since I will most probably get nothing in > response but more of ad hominem attacks, why should I even bother? > I might be willing to discuss it with you if I thought it would resolve an issue. I think the better discussion would be how to resolve the differences in the testing results. Perhaps different static files when the build and target system is MINGW. Earnie |
From: Eli Z. <el...@gn...> - 2006-01-07 13:21:39
|
> From: "Earnie Boyd" <ea...@us...> > Cc: cod...@ho..., Eli Zaretskii <el...@gn...> > Date: Sat, 7 Jan 2006 06:22:20 -0500 > > It became /c because I didn't like /cygdrive/c. Both /c and /cygdrive/c have the same problem in the context of what we are discussing. > > sed -e /c/s/foo/bar/g > > There are more ways to write the inline script than there are ways to deal > with UNIX to DOS/WINDOWS translations. MSYS isn't perfect I don't think asking for not breaking program invocation is asking for perfection. > its goal was and > still is simply to provide a tool with a minimum number of executables to be > able to execute a typical configure && make to allow maintainers a common > mechanism for building packages between UNIX and Windows. There are some > major sized packages, I'm thinking in particular of ACE/TAO, using MSYS and > MinGW to build the windows based versions of their applications. I have no doubt that MSYS is a useful package. I'm suggesting a way that I think will make it more useful. In particular, right now the MSYS port of Bash cannot be reliably used with non-MSYS programs, even if they were compiled with the MinGW port of GCC. To me, this is a grave limitation, not unlike a similar limitation with Cygwin programs: if you use some basic tool from MSYS/Cygwin, you eventually find that only MSYS/Cygwin builds will work reliably. > > I think it's clear that, although this looks like a file name, it > > really isn't, and treating it as a file name that can be converted to > > C:\s\foo\bar will produce utterly unexpected results. > > Well, actually, your example wouldn't change /c/s/foo/bar/g to c:\s\foo\bar > because sed uses the MSYS runtime. If I use the port of Sed provided by MSYS, yes; but my Sed is a native MinGW build. I don't think it is justified for MSYS to force me to use only MSYS executables--this is the main reason why I don't use Cygwin. |
From: Earnie B. <ea...@us...> - 2006-01-07 19:57:40
|
On Sat, 07 Jan 2006 15:21:28 +0200, Eli Zaretskii wrote > > From: "Earnie Boyd" <ea...@us...> > > Cc: cod...@ho..., Eli Zaretskii <el...@gn...> > > Date: Sat, 7 Jan 2006 06:22:20 -0500 > > > > It became /c because I didn't like /cygdrive/c. > > Both /c and /cygdrive/c have the same problem in the context of what > we are discussing. > I was just telling you why it was /c; I didn't think you'd be impressed. > > > sed -e /c/s/foo/bar/g > > > > There are more ways to write the inline script than there are ways to deal > > with UNIX to DOS/WINDOWS translations. MSYS isn't perfect > > I don't think asking for not breaking program invocation is asking > for perfection. > I took a product that wasn't really working well for MinGW, at least at the time (don't know about now), and created a product that works at least 98% of the time. So, yes you're asking for perfection. > > its goal was and > > still is simply to provide a tool with a minimum number of executables to be > > able to execute a typical configure && make to allow maintainers a common > > mechanism for building packages between UNIX and Windows. There are some > > major sized packages, I'm thinking in particular of ACE/TAO, using MSYS and > > MinGW to build the windows based versions of their applications. > > I have no doubt that MSYS is a useful package. I'm suggesting a way > that I think will make it more useful. More useful than 98% of the time? I've stated my goal, I've reached it. > In particular, right now the > MSYS port of Bash cannot be reliably used with non-MSYS programs, > even if they were compiled with the MinGW port of GCC. To me, this > is a grave limitation, not unlike a similar limitation with Cygwin > programs: if you use some basic tool from MSYS/Cygwin, you > eventually find that only MSYS/Cygwin builds will work reliably. > I agree. It would be nice to be able to do that. There are ports that others have done but I don't know if they are any more useful. > > > I think it's clear that, although this looks like a file name, it > > > really isn't, and treating it as a file name that can be converted to > > > C:\s\foo\bar will produce utterly unexpected results. > > > > Well, actually, your example wouldn't change /c/s/foo/bar/g to c:\s\foo\bar > > because sed uses the MSYS runtime. > > If I use the port of Sed provided by MSYS, yes; but my Sed is a > native MinGW build. I don't think it is justified for MSYS to force > me to use only MSYS executables--this is the main reason why I don't > use Cygwin. True. I don't force anyone to use the executables provided by MSYS unless they want help using them. The tools I provided using the MSYS runtime were provided that way because I didn't and don't have the time to port them appropriately. I also think you're correct to a point but that correctness doesn't mean that I like it that way. I happen to like the filesystem mapping MSYS does and use it to my benefit. As I hear you, you would rather that someone port bash to native windows and forget about the POSIX nature MSYS provides. I spent six months off and on looking at bash and decided to fork Cygwin. Feel free to give the bash port a go. I would even suggest MinGW host it if you wish. But what would one do with scripts that start like ``#! /bin/sh''; e.g autoconf generated configure scripts? Oh, yeah we have to map /bin to something physical which happens to be the location of the executable or dll. And then others start like ``#! /usr/bin/sh'' (shame on the programmer) so we should map /usr/bin to the location of the executable or dll as well. Ok, now we need to point / somewhere that is relavent to /bin; that becomes the parent directory of the location of the executable or dll. Earnie |
From: Eli Z. <el...@gn...> - 2006-01-08 04:37:12
|
> From: "Earnie Boyd" <ea...@us...> > Cc: min...@li..., kei...@to..., > cod...@ho... > Date: Sat, 7 Jan 2006 14:56:31 -0500 > > > > MSYS isn't perfect > > > > I don't think asking for not breaking program invocation is asking > > for perfection. > > I took a product that wasn't really working well for MinGW, at least at the > time (don't know about now), and created a product that works at least 98% of > the time. So, yes you're asking for perfection. > > > > its goal was and > > > still is simply to provide a tool with a minimum number of executables to be > > > able to execute a typical configure && make to allow maintainers a common > > > mechanism for building packages between UNIX and Windows. There are some > > > major sized packages, I'm thinking in particular of ACE/TAO, using MSYS and > > > MinGW to build the windows based versions of their applications. > > > > I have no doubt that MSYS is a useful package. I'm suggesting a way > > that I think will make it more useful. > > More useful than 98% of the time? I've stated my goal, I've reached it. Well, if the consensus here is that MSYS doesn't need any improvement, because it's reached its goal, then of course this whole conversation is futile. > As I hear you, you would rather that someone port bash to native windows and > forget about the POSIX nature MSYS provides. Yes, a native Windows port of Bash is sorely needed, IMO. How much of Posix should be left in it is a matter of practical compromises; in general, I don't expect it to lose too much, but the Posix /foo/bar absolute file names is indeed one of the requirements that should be lost, since supporting it on Windows means more trouble than it's worth, in my experience. > Feel free to give the bash port a go. Thanks for the suggestion, I'm already working on porting a shell. Unfortunately, my free time is so limited that I'm not sure that work will ever be finished. > But what would one do with scripts that start like ``#! /bin/sh''; > e.g autoconf generated configure scripts? Oh, yeah we have to map > /bin to something physical which happens to be the location of the > executable or dll. And then others start like ``#! /usr/bin/sh'' > (shame on the programmer) so we should map /usr/bin to the location > of the executable or dll as well. One solution for these problems is to try the named location verbatim (i.e., on the current drive, whatever that happens to be), and if that doesn't find the executable, look for its basename, i.e. `sh' in your example, along the current value of PATH. (Of course, for each directory mentioned in PATH, one should try all the known executable extensions, like those mentioned in PATHEXT, .exe, .bat, .cmd, etc.) This is what the DJGPP project did, and it worked just fine. It's also what users on Windows generally expect, I think. |
From: Earnie B. <ea...@us...> - 2006-01-08 13:36:56
|
----- Message from el...@gn... --------- Date: Sun, 08 Jan 2006 06:35:42 +0200 From: Eli Zaretskii <el...@gn...> Reply-To: Eli Zaretskii <el...@gn...> Subject: Re: [Mingw-users] Re: make'ing make-3.18beta4 under mingw/msys - "undefined reference to `sleep'" To: Earnie Boyd <ea...@us...> >> >> More useful than 98% of the time? I've stated my goal, I've reached it. > > Well, if the consensus here is that MSYS doesn't need any improvement, > because it's reached its goal, then of course this whole conversation > is futile. > I didn't say MSYS couldn't use improvement, I said I had reached my goal. The source is available in CVS for anyone to submit patches against. > >> Feel free to give the bash port a go. > > Thanks for the suggestion, I'm already working on porting a shell. > Unfortunately, my free time is so limited that I'm not sure that work > will ever be finished. > [OT] Write to me personally about which one. >> But what would one do with scripts that start like ``#! /bin/sh''; >> e.g autoconf generated configure scripts? Oh, yeah we have to map >> /bin to something physical which happens to be the location of the >> executable or dll. And then others start like ``#! /usr/bin/sh'' >> (shame on the programmer) so we should map /usr/bin to the location >> of the executable or dll as well. > > One solution for these problems is to try the named location verbatim > (i.e., on the current drive, whatever that happens to be), and if that > doesn't find the executable, look for its basename, i.e. `sh' in your > example, along the current value of PATH. (Of course, for each > directory mentioned in PATH, one should try all the known executable > extensions, like those mentioned in PATHEXT, .exe, .bat, .cmd, etc.) > This is what the DJGPP project did, and it worked just fine. It's > also what users on Windows generally expect, I think. > I understand. I'm thinking on this. Triggered by MSYS_DJGPP_EMUL environment variable: 1) Skip all mount emulation. 2) Skip all path translation. 3) Default to text mode i/o. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Al S. <al....@sc...> - 2006-01-07 11:51:34
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eli Zaretskii wrote: >>Cc: "Luke Dunstan" <cod...@ho...>, >> min...@li... >>From: Keith MARSHALL <kei...@to...> >>Date: Fri, 6 Jan 2006 15:10:24 +0000 >> >>Eli Zaretskii wrote, quoting Luke Dunstan: >> >>>>FWIW I agree that your comments were arrogant >>> >>>Since when expressing an opinion that something is a bug counts as >>>arrogant? >> >>The arrogance lay not in the expression of the opinion per se, but in >>the manner of its expression; if you persistently indicate that your >>opinions are "not so humble" -- as you do -- that is, by definition, >>downright arrogance. > > > Ah, okay, so an opinion is either humble, if it's explicitly qualified > as such, or arrogant otherwise? Don't you think your standards are a > tad too touchy and unrealistic? No, but it is arrogant when _EXPLICTLY_ qualified as such ie. _NOT_ So Humble. What do you think "In my not so humble opinion" means? - -- Al Slater -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDv6tFz4fTOFL/EDYRAssEAJ9Ki9L0VKXG/L8lDVz3K28b7MbMmACeLVQr 1Uil/PVohoagLMMPi8bQlEg= =Zfed -----END PGP SIGNATURE----- |