Re: Windows patches for the next release
On Thu, Oct 03, 2013 at 07:05:42PM +0300, Eli Zaretskii wrote:
Date: Thu, 3 Oct 2013 01:23:15 -0400
From: Christopher Faylor cgf-use-the-mailinglist-ple...@gnu.org
@@ -2001,13 +2005,17 @@ abspath (const char *name, char *apath)
}
else
{
+#ifdef __CYGWIN__
+ if (STOP_SET (name[0], MAP_PATHSEP))
+ root_len = 1;
+#endif
I've eyeballed the patch even though I won't be releasing a version of
make which has this turned on.
I think the above unnecessary if HAVE_DOS_PATHS is true and should be
#if defined(__CYGWIN__) defined(HAVE_DOS_PATHS)
You are right, I pushed a fix.
You got it even with my garbled sentence. Thanks.
I'm not sure it's correct to consider \a to be an absolute path in the
same way that /a is since they mean different things to Cygwin but I
guess that's not something that I have to worry about.
I thought about that as well. I actually think that Cygwin should not
consider a backslash as a directory separator, even if HAVE_DOS_PATHS
is defined. What do you think?
Hmm. I'm not sure. It wouldn't bother me but there may be people who
want to be able to use backslashes.
Anyway, such a change modifies behavior (under HAVE_DOS_PATHS), and
its prerequisite is to use STOP_SET everywhere in Make. So I think I
will make that change after the release (unless you, or someone else
object).
Sounds good.
cgf
___
Make-w32 mailing list
Make-w32@gnu.org
https://lists.gnu.org/mailman/listinfo/make-w32
Re: Windows patches for the next release
On Tue, Oct 01, 2013 at 07:52:02PM +0300, Eli Zaretskii wrote:
From: Paul Smith psm...@gnu.org
Cc: bug-...@denis-excoffier.org, pavel_fe...@mail.ru, make-w32@gnu.org
Date: Tue, 01 Oct 2013 01:08:32 -0400
On Mon, 2013-09-30 at 18:15 +0300, Eli Zaretskii wrote:
I suggest another RC, I think the changes since the last one are
non-trivial.
OK, I created a new RC, available now on make-alpha.
Thanks. It still builds fine on Windows using MinGW GCC.
I don't personally plan to make any more changes, so as soon as you feel
you're happy with the Windows support I will release.
Here's the patch for $abspath that should fix the Cygwin build. Would
Cygwin people please test it, and in particular see if the related
failures in the test suite are gone? I don't have a Cygwin
environment to even compile with Cygwin.
I'd especially appreciate if Chris could at least eyeball the patch.
@@ -2001,13 +2005,17 @@ abspath (const char *name, char *apath)
}
else
{
+#ifdef __CYGWIN__
+ if (STOP_SET (name[0], MAP_PATHSEP))
+ root_len = 1;
+#endif
I've eyeballed the patch even though I won't be releasing a version of
make which has this turned on.
I think the above unnecessary if HAVE_DOS_PATHS is true and should be
#if defined(__CYGWIN__) defined(HAVE_DOS_PATHS)
I'm not sure it's correct to consider \a to be an absolute path in the
same way that /a is since they mean different things to Cygwin but I
guess that's not something that I have to worry about.
cgf
___
Make-w32 mailing list
Make-w32@gnu.org
https://lists.gnu.org/mailman/listinfo/make-w32
Re: Build with cygwin gcc
On Mon, Jun 04, 2012 at 09:29:35PM +0300, Eli Zaretskii wrote: Date: Mon, 4 Jun 2012 10:48:53 -0700 (PDT) From: Stacy Leon stac...@comcast.net I guess wonder how they produce the prepackaged cygwin make. When I use their prepackaged make it cannot handle drive letters at all. By modifying the sources, how else? Take a look at their sources, they must have a source distribution, since the GPL requires that. Yes, Cygwin is a free software project as should be pretty clear from the web site. cgf ___ Make-w32 mailing list Make-w32@gnu.org https://lists.gnu.org/mailman/listinfo/make-w32
Re: is MS-DOS the same as Windows?
On Tue, Jan 19, 2010 at 10:54:42PM +0200, Eli Zaretskii wrote: From: Mark Galeck (CW) mgal...@brocade.com Date: Tue, 19 Jan 2010 11:49:59 -0800 Accept-Language: en-US acceptlanguage: en-US When MS-DOS is mentioned in the GNU make manual, does this automatically mean this applies to the version of GNU-make for any flavor of Windows? No, it means only the MS-DOS port. The Windows port is different. And, the Cygwin port of make, which runs on Windows, is different from the native Windows port. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Make on Windows
On Tue, Jul 15, 2008 at 05:15:43PM +0530, raghuvir konanki wrote: I need to execute the make utility on windows. I downloaded a software called Blog 0.2 which needs the make utility to execute its setup file. So could you please help me with that. Seems like google.com would be your friend here. Most of the first hits when you type make on windows show you where to find make for windows. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: make 3.81 and MS-DOS paths (e.g. C: or drive letter paths)
On Thu, Jul 03, 2008 at 12:41:16PM -0400, Paul Smith wrote: On Thu, 2008-07-03 at 11:26 -0400, Bill Hoffman wrote: I think this is a known limitation, that the job server is not implemented on certain platforms. I googled a bit, and it seemed like it has something to do with having or not having named pipes. Perhaps some of the gnu make folks could elaborate on this issue. Make jobserver doesn't use named pipes, at least not on POSIX systems. It does, however, require fully capable POSIX pipes, in particular ones that are inherited by/shared across multiple processes and which can be read from and written to by multiple processes simultaneously. Since Cygwin doesn't have fully functional named pipes GNU make couldn't be relying on them anyway. There shouldn't be any problem with regular pipes in modern Windows versions. There were some irregularities in the Windows 9x series but I don't think that should really be an issue for GNU make these days. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: VPATH of the form C:/foo
On Sun, Dec 02, 2007 at 11:52:41AM +0100, Benoit Sigoure wrote: On Dec 2, 2007, at 3:37 AM, Christopher Faylor wrote: On Thu, Nov 29, 2007 at 11:36:45PM +0100, Benoit Sigoure wrote: On Nov 29, 2007, at 10:30 PM, Eli Zaretskii wrote: From: Benoit Sigoure Date: Thu, 29 Nov 2007 22:12:52 +0100 [EMAIL PROTECTED] ~ $ make -p VPATH=C:/cygwin | grep -A2 -i vpath [...] -- # VPATH Search Paths # No `vpath' search paths. # No general (`VPATH' variable) search path. Ah, I see the problem: the native Windows port (which is what I have) converts all `:' that are not part of drive letter spec to `;' (by calling convert_vpath_to_windows32), and then Make parses that using `;' as PATH_SEPARATOR_CHAR, which makes C:/foo:D:/bar work. But in the Cygwin build, convert_vpath_to_windows32 is not called and PATH_SEPARATOR_CHAR is `:', so this does not work. I will try to post an experimental patch soon. Thanks for pointing out this problem. Thank you very much, I'm eager to see the patch ;) This does raise the question of why you'd be using a cygwin version of make if you need to use colon paths. Good question. The VPATH variable is set by a script that calls `make'. This variable is also used to invoke native Windows tools, so it's more convenient to use the C:/Foo/Bar notation, which has the advantage of working with both native applications and Cygwin ones (while being nice with the shell by avoiding backslashes). Why not convert the VPATH to UNIX format with cygpath ? cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: VPATH of the form C:/foo
On Sun, Dec 02, 2007 at 06:41:47PM +0100, Benoit Sigoure wrote: On Dec 2, 2007, at 6:13 PM, Christopher Faylor wrote: On Sun, Dec 02, 2007 at 11:52:41AM +0100, Benoit Sigoure wrote: On Dec 2, 2007, at 3:37 AM, Christopher Faylor wrote: This does raise the question of why you'd be using a cygwin version of make if you need to use colon paths. Good question. The VPATH variable is set by a script that calls `make'. This variable is also used to invoke native Windows tools, so it's more convenient to use the C:/Foo/Bar notation, which has the advantage of working with both native applications and Cygwin ones (while being nice with the shell by avoiding backslashes). Why not convert the VPATH to UNIX format with cygpath ? That's the workaround we use ATM, but I still consider this as a bug that the Windows port of make doesn't deal nicely with Windows paths for this particular feature. I would prefer to avoid this sort of hack in my scripts: Ok. You've used the bug word so that's it for me. Nothing more to talk about. Have fun. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Switching from CVS to GIT
On Tue, Oct 16, 2007 at 05:23:11PM +0100, Dave Korn wrote: On 16 October 2007 16:56, David Brown wrote: On Tue, Oct 16, 2007 at 02:25:21AM -0400, Eli Zaretskii wrote: On the other hand, what packages have 100K files? If there's only one -- the Linux kernel -- then I think this kind of performance is for all practical purposes unimportant on Windows, because while it is reasonable to assume that someone would like to use git on Windows, assuming that someone will develop the Linux kernel on Windows is -- how should I put it -- _really_ far-fetched ;-) Oh, I wish others could think this clearly. Quoting a serious line off of a task list at an unnamed company: - Make Linux kernel compile under windows. I don't think it will move past just being a wish list item, but there seem to be people that think it should be done. Admittedly, they don't want developers doing it on windows, but want to integrate kernel building into a windows-heavy build and release process. Do that kind of thing here all the time, hence my previous post. Apart from the netfilter stuff with the filenames-that-match-in-all-but-case, no real problems, took me a couple of hours one afternoon. Ditto. Coincidentially enough this is the reason I wrote managed mode for cygwin's mount. But, we're pretty far off-topic aren't we? cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Switching from CVS to GIT
On Sat, Oct 13, 2007 at 10:22:56PM +0200, Ram??n Garc??a wrote: In my opinion, distributed control version systems like GIT or Mercurial are the way to go in the long term. In Sun all the repositories are (or are being migrated to) Mercurial. There is only one serious limitation with GIT: each developer must have a complete repository, that is, it is not posible to work with a subdirectory. But this is not an issue for projects like GNU Make. I have no experience with GIT on Windows, but there is a page about it in the GIT Wiki: http://git.or.cz/gitwiki/WindowsInstall That page seems to imply either MSys or Cygwin. Neither of those is a pure windows-only solution. I can see why people wouldn't want to install cygwin + perl + bash + tk + whatever just to do source control. I was reading the git mailing list for a while and one person was rabidly anti-cygwin - enough for me to eventually decide it wasn't worth getting a jolt of adrenaline one morning a week. I thought this person was actively working on a mingw port and, attitude aside, he seemed very competent. If the direction of the port was to use *MSYS* to do some of the heavy lifting then that's just too funny. Someone mentioned mercurial already. There is YA enthusiastic camp of people who think it is superior to git. The author made a pretty compelling case in a presentation I saw at a past OLS. I'm wondering if it is somewhat lighter weight in terms of number of packages that need to be installed. I don't know if Paul would consider this or not. It means convincing savannah sysadmins that this is a good idea, I guess. I could sponsor the hosting of GNU make at sourceware.org, which has mercurial installed, but I guess that's a sort of radical step. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Switching from CVS to GIT
On Sat, Oct 13, 2007 at 12:37:46PM -0400, Paul Smith wrote: Hi all; I'm considering switching from CVS to another form of SCM. Currently, Savannah supports (in addition to CVS) GNU arch and GIT. If SVN were supported I'd probably go for that, because (a) it has great support for alternative OSs like Windows, etc.; and (b) GNU make development is currently straightforward enough that the advanced features of GIT (advanced merging and peer-to-peer development) aren't critical. However, SVN is not an option and I would like some more advanced SCM capabilities such as moving/renaming files (I've been putting off some code cleanups waiting for this). It seems like GIT is where the mindshare is these days, plus a number of the other autotools projects have already migrated (or are in the middle of migrating) to GIT, so that's what I'd go with. As with the other projects, we'll maintain a read-only CVS mirror of the main GIT archive at least for the time being so people can use that to obtain code, the same way they do today. Still, it would be better if people had more direct access; I'd be happy to delegate support for Windows (MINGW, Cygwin, etc.) and pull those from other GIT repositories if that seems reasonable. I don't really know what the current state-of-the-art is WRT GIT on non-POSIX systems, so... please give me your opinions on this change. git is available for download from the standard Cygwin installation and it reportedly works fine. Isn't there a pure MinGW (not msys) version too? cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Native WIN32 GNU make?
On Tue, May 08, 2007 at 09:20:54PM -0400, Earnie Boyd wrote: Quoting Mark Txx [EMAIL PROTECTED]: Any other native WIN32 solutions? such as mingw This is the one I would suggest. Along with MSYS (also supplied by MinGW) which is a fork of an older version of Cygwin tailored to a mingw32 build environment. The MinGW-based make is undoubtedly going to be faster than the Cygwin version so, if you don't need any of the other stuff that Cygwin offers then MinGW should be a big win. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Problems with echo. (echo period)
On Mon, Apr 23, 2007 at 03:22:40PM +0100, Dave Korn wrote: On 21 April 2007 10:02, Eli Zaretskii wrote: [ got left sitting in my drafts folder over the weekend. ] From: Dave Korn Date: Fri, 20 Apr 2007 17:18:01 +0100 On 20 April 2007 17:15, Aaron Shatters wrote: As I noted previously, there are many workarounds to this problem. I am interested in fixing the root cause. After all of this investigation, do we have consensus that this is a limitation of make? More importantly, do we have consensus that it should be fixed? We seem to have run out of reasons for not fixing this problem. Since echo. is clearly a shell builtin, and since the code is supposed to recognize shell builtins and hand them off to the shell, I would support fixing this in the source. I don't think echo. is a shell builtin. It is a peculiar feature of the cmd.exe command parser. This is a semantic quibble. The shell builtin is echo, echo. is an alternative form, and the main point is: I believe that the real issue here is that, in some cases, cmd.exe throws away a '.' after a built-in command. So, it isn't, IMO, strictly correct to add an 'echo.'. If we really wanted to do this, it seems like it would be better to recognize those built-ins which allow a '.' and eat a dot in those case. cmd.exe's handling of '.' seems to be funky, though. It isn't as simple as saying just ignore the dot since some commands (like dir or echo) seem to semi-ignore it while others (cd) seem to be almost short-circuited by it. IMO, cmd.exe's handling of '.' in these scenarios is strange enough that it's best to just not bother with it in make, as Eli has maintained. Otherwise, it seems like we'd potentially be spending a lot of time tweaking corner cases or discovering that different versions of cmd.exe/command.com behave differently. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: $(shell ...) and SHELL problems in 3.81
On Sun, Apr 15, 2007 at 06:16:56AM +0300, Eli Zaretskii wrote: Date: Sat, 14 Apr 2007 17:59:13 -0400 From: Christopher Faylor Cc: Please don't bother reporting problems to the Cygwin mailing list if the problem is due to the use of a non-POSIX shell in make. That is not supported. It goes against the whole concept of Cygwin. I think you interpret the problem incorrectly. GNU Make allows any program to be used as SHELL, and promises only that the named SHELL will be called once for each command it runs. I don't think anyone claimed that cmd.exe was not being run. However, since cmd.exe does not qualify as a POSIX shell, it is not producing the desired outcome, anymore than if SHELL had been set to /bin/cat. I'd be surprised to learn that the Cygwin port withdraws from this promise of GNU Make, which works on all Posix platforms. cmd.exe does not take the same arguments as a UNIX shell so there is no reason to assume that it should work when invoked by a program like make which assumes a UNIX shell. Cygwin may try to be an island of POSIX in a sea of Windows but as soon as you leave the island by running cmd.exe you have to expect trouble. I don't have the POSIX specification handy but I'd be surprised of cmd.exe qualified as a POSIX shell since, AFAICT, the POSIX shell specification is based on the Bourne Shell which accepts -c as a command-line argument. Above and beyond that point, however, it is not a goal of Cygwin to operate flawlessly with cmd.exe. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: $(shell ...) and SHELL problems in 3.81
On Mon, Apr 16, 2007 at 12:04:59AM +0300, Eli Zaretskii wrote: On Sun, Apr 15, 2007 at 06:16:56AM +0300, Eli Zaretskii wrote: Date: Sun, 15 Apr 2007 16:09:39 -0400 From: Christopher Faylor [EMAIL PROTECTED] I think you interpret the problem incorrectly. GNU Make allows any program to be used as SHELL, and promises only that the named SHELL will be called once for each command it runs. I don't think anyone claimed that cmd.exe was not being run. However, since cmd.exe does not qualify as a POSIX shell, it is not producing the desired outcome, anymore than if SHELL had been set to /bin/cat. Cygwin may try to be an island of POSIX in a sea of Windows but as soon as you leave the island by running cmd.exe you have to expect trouble. I don't have the POSIX specification handy but I'd be surprised of cmd.exe qualified as a POSIX shell since, AFAICT, the POSIX shell specification is based on the Bourne Shell which accepts -c as a command-line argument. If -c is the problem (which I agree it probably is), then it's not specific to cmd.exe; any program that doesn't grok -c as a shell does will behave that way. For example, cat or perl, even if they are Cygwin programs. Yes. I've put back the part that you snipped where I *made* the point about cat. I don't see any reason for you to cut my point and then claim it as your own. There is no Cygwin component here. If you set your SHELL to something which is not the type of shell that make expects, it will not work. That is make working as designed and it is not an issue that needs to be taken up with the cygwin mailing list. Above and beyond that point, however, it is not a goal of Cygwin to operate flawlessly with cmd.exe. But Cygwin doesn't (AFAIK) do anything to deliberately defeat cmd.exe more than it does with any other program. And that wasn't my point. My point was that if there is some subtle thing that cmd.exe needs in order to be used as a shell and Cygwin isn't supplying we will not be extremely interested in standing on our heads to supply it. I am, again, trying to dissuade anyone from the potentially discouraging experience of expecting that their cmd.exe woes will be actively considered on the Cygwin mailing list. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: $(shell ...) and SHELL problems in 3.81
On Mon, Apr 16, 2007 at 12:46:55AM +0100, Dave Korn wrote: On 15 April 2007 22:54, Christopher Faylor wrote: On Mon, Apr 16, 2007 at 12:04:59AM +0300, Eli Zaretskii wrote: On Sun, Apr 15, 2007 at 06:16:56AM +0300, Eli Zaretskii wrote: There is no Cygwin component here. If you set your SHELL to something which is not the type of shell that make expects, it will not work. That is make working as designed and it is not an issue that needs to be taken up with the cygwin mailing list. Above and beyond that point, however, it is not a goal of Cygwin to operate flawlessly with cmd.exe. But Cygwin doesn't (AFAIK) do anything to deliberately defeat cmd.exe more than it does with any other program. And that wasn't my point. My point was that if there is some subtle thing that cmd.exe needs in order to be used as a shell and Cygwin isn't supplying we will not be extremely interested in standing on our heads to supply it. I am, again, trying to dissuade anyone from the potentially discouraging experience of expecting that their cmd.exe woes will be actively considered on the Cygwin mailing list. I tried out the testcase. It isn't actually hung, it's waiting for console input. If you type 'exit' and hit return, you get dropped back to a cmd.exe shell; once more and you get dropped back to a bash prompt. I haven't looked closer, but I guess that means that cmd.exe doesn't like being hooked up to a cygwin-simulated pty - which is indeed not a supported use-case. Actually it means that cmd.exe doesn't know what to do with a -c option. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: $(shell ...) and SHELL problems in 3.81
On Fri, Apr 13, 2007 at 12:08:08PM +0300, Eli Zaretskii wrote: If you cannot debug this yourself, I suggest to take this up with the Cygwin folks on the Cygwin mailing list. I don't use Cygwin myself, so I cannot debug this problem. Please don't bother reporting problems to the Cygwin mailing list if the problem is due to the use of a non-POSIX shell in make. That is not supported. It goes against the whole concept of Cygwin. cgf ___ Make-w32 mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/make-w32
Re: performance issue with cgywin make
On Fri, Dec 08, 2006 at 08:14:14AM -0500, Earnie Boyd wrote: Quoting Eli Zaretskii [EMAIL PROTECTED]: Date: Thu, 07 Dec 2006 16:59:05 -0500 From: Earnie Boyd Alternatives to stat using the windows API though may be a different issue for the native version. You won't be able to use those alternatives for Cygwin or MSYS. Why can't those alternatives be used for Cygwin or MSYS? Because you'd have headaches with the emulated POSIX paths. Right. That plus the whole point of Cygwin (MSYS) is to use the linux-like interface. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: performance issue with cgywin make
On Thu, Dec 07, 2006 at 05:11:37PM -0500, Bill Hoffman wrote: Earnie Boyd wrote: Quoting Bill Hoffman [EMAIL PROTECTED]: So, if I run gmake (the patched cygwin version) and nmake (Microsoft's make) on roughly the same tree. (CMake can generate files for either.) nmake is able to check the depend information about twice as fast as gmake can. I suspect that the problem is in the use of stat. Although windows/ cygwin provide stat, there are significantly faster versions of stat available via direct windows system calls. We had a similar problem in CMake, and use the following code in windows to compare times stamps of Cygwin's performance of stat shouldn't be a concern for this list. Take it back to the cygwin users list please. Alternatives to stat using the windows API though may be a different issue for the native version. You won't be able to use those alternatives for Cygwin or MSYS. OK, for the moment lets forget about cygwin make. The native build of make should have the same issue, as it is calling stat which is provided in the winapi, but is slow. Can someone give me a pointer to where I could put different calls into make just so I can try it and see if it helps. Thanks. Why should the msvcrt _stat be slow? I wouldn't assume that to be the case. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Problems with latest Cygwin make patch; builds OK but binary segfaults
On Fri, Sep 08, 2006 at 11:47:22PM +0300, Eli Zaretskii wrote: Date: Fri, 8 Sep 2006 13:51:21 -0400 From: Christopher Faylor So, again, I'd like to go slowly and carefully with this change. I agree, and said I would wait, but I can't wait indefinitely. Eventually, if no one else cares to try these changes, they will go in. Personally, I think it sets a bad precedent to suggest that you'll apply a patch over the potential objections of the project lead for the affected system. However, you might as well go ahead and check in the patch. If someone notes a problem then presumably it can be reported back to this mailing list. But, at least, you won't have to suffer with an indefinite wait before the patch is checked in. And in the meantime, since this is free software, if I don't agree that this change should be in the Cygwin release, I can always back it out in the next release. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Problems with latest Cygwin make patch; builds OK but binary segfaults
On Tue, Sep 05, 2006 at 09:23:41PM +0300, Eli Zaretskii wrote: From: William Sheehan [EMAIL PROTECTED] Date: Tue, 5 Sep 2006 11:03:22 -0700 Thanks for catching this; your patch works perfectly and does not demonstrate any of the problems I was encountering before. Thanks for testing. Paul, I recommend this patch (reproduced below) for inclusion in the development sources. There's one more problem with HAVE_DOS_PATHS: $abspath doesn't support it. I already submitted a patch for that, but it will not DTRT for Cygwin, now that Cygwin supports HAVE_DOS_PATHS. I will rework that patch and resubmit it soon. We've only had one success report for this so far, and even that seemed to have generated some confusion. Given all of the hoopla on the Cygwin list about this functionality, I'd feel much more comfortable if a few of the complainers there tested this also. I'm not willing to go through this amount of pain very often so I'd like to make sure we got things right the first time. So, I'd prefer holding off until a couple more people try this out. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Fix for HAVE_DOS_PATHS build on cygwin
On Mon, Aug 21, 2006 at 05:34:51AM -0400, Eli Zaretskii wrote: Date: Sat, 19 Aug 2006 10:30:09 -0400 From: William A. Hoffman Okay, here's a patch that replaces the previous one. Bill, could you please see that it compiles and works for you? Thanks. Compiles and works! Great, thanks. I'm travelling right now, and won't be back until a week from now. Is it possible that you or Chris post a message to the Cygwin list asking them to try the patch? It should be enough to point them to the message in the archives of this list where I posted the patch. (Please remind them to run autoconf and autoheader before they reconfigure and rebuild.) I'm not going to be promoting this patch on the mailing list. If Bill wants to do so, that is fine, however. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Fix for HAVE_DOS_PATHS build on cygwin
On Fri, Aug 18, 2006 at 01:55:00PM +0300, Eli Zaretskii wrote: Date: Thu, 17 Aug 2006 17:32:19 -0400 From: Christopher Faylor [EMAIL PROTECTED] What is best should be decided by the Cygwin community, so you may wish to discuss this on the Cygwin list. (If it matters, my advice would be to allow only the forward slashes for the Cygwin port, as it gives enough rope to get things done for minimal risk, and because backslashes are not 100% supported even in the native builds.) Whatever the decision, this is precisely the reason why the patch we eventually decide upon should be tested with as many Cygwin Makefile's as possible. I guess my concern is that there will be times where a '\' will not be interpreted as a quoting character when it really should be. I can't think of any examples, though. The only examples I can think of is passing \b and \n to programs like `echo' or `printf'. Even then, I'm not sure I can come up with a specific case where the current code would cause a failure. So, Chris, are you okay with leaving this behavior in the Cygwin build, or do you wish to opt for a safer /-only support for drive letters? We need to make a decision, and I'd rather have yours than decide on my own. (I didn't see any discussion of this on the Cygwin list, either.) Since I can't come up with a failure case, I think it's ok to leave it as is. If make doesn't deal with backslashes it will surely be viewed as yet another attempt on my part to torture people with software. If problems do crop up, I'll report them here. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: mingw make problems
On Fri, Aug 18, 2006 at 09:07:33AM -0400, Earnie Boyd wrote: Quoting Bill Hoffman [EMAIL PROTECTED]: At 04:48 PM 8/17/2006, Christopher Faylor wrote: I don't understand why MinGW's make should be using anything like /bin/sh. Shouldn't it be using cmd.exe or command.com? It seems that if it finds sh.exe in the path it uses it. Remember the chars_sh and chars_dos thing that is switched at run time, that switch is triggered by the finding of sh.exe in the PATH. And that shouldn't change. Personally, I think that a mingw make should just rely on cmd and a msys make should rely on sh. But, it looks like you already have had this discussion, so don't feel the need to educate me on this. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Fix for HAVE_DOS_PATHS build on cygwin
On Fri, Aug 18, 2006 at 08:42:15PM +0300, Eli Zaretskii wrote: Date: Thu, 17 Aug 2006 12:38:29 -0400 From: Bill Hoffman /* Handle other OSs. */ ! #if defined(HAVE_DOS_PATHS) !defined(__CYGWIN__) # define PATH_SEPARATOR_CHAR ';' #elif defined(VMS) # define PATH_SEPARATOR_CHAR ',' This is probably too big a change for this particular problem (and maybe it's already been discussed to death) but I don't see why this setting couldn't be in configure.in, too. Then MinGW could set PATH_SEPARATOR_CHAR to ';', VMS could set it to ',' (shouldn't that be '.'?), and Cygwin and every other UNIX system could just use the default. Sure, this seems to produce the correct behavior. If you want to make it a configure.in thing, then provide a patch. I was just going along with the existing style of the code in this case. As a matter of fact, configure already computes the right value for PATH_SEPARATOR_CHAR, it just calls it PATH_SEPARATOR. I will try to come up with a suitable patch to use that value directly. For the record, Eli, I REALLY appreciate the time and attention you're giving this matter. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Fix for HAVE_DOS_PATHS build on cygwin
On Fri, Aug 18, 2006 at 01:58:14PM -0400, William A. Hoffman wrote: At 01:52 PM 8/18/2006, Christopher Faylor wrote: For the record, Eli, I REALLY appreciate the time and attention you're giving this matter. I will second that. At the end of the day, the right thing is getting done. Thanks. And, the right thing was first proposed more than a month ago. Who'd have thought? cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Fix for HAVE_DOS_PATHS build on cygwin
On Fri, Aug 18, 2006 at 01:55:16PM -0400, William A. Hoffman wrote: At 01:29 PM 8/18/2006, Eli Zaretskii wrote: We cannot patch config.h.in, it's a generated file. Actually config.h is the generated file, and config.h.in is the source, but if you fix configure this part of the patch is no good. /* config.h.in. Generated from configure.in by autoheader. */ cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Fix for HAVE_DOS_PATHS build on cygwin
On Fri, Aug 18, 2006 at 09:54:31PM +0300, Eli Zaretskii wrote:
+# ifdef HAVE_DOS_PATHS
+ /* This is required if the MSYS/Cygwin ports (which do not define
+ WINDOWS32) are compiled with HAVE_DOS_PATHS defined, which uses
+ sh_chars_sh[] directly (see below). The value is identical to
+ the one above for WINDOWS32 platforms. */
+ static char sh_chars_sh[] = #;\*?[]|(){}$`^;
+# endif/* HAVE_DOS_PATHS */
Why would sh_chars_sh be different from the standard sh_chars? The
above would not treat '~' and '!' specially even though they are special
to bash. Since the sh_chars on Cygwin (and presumably MSYS) are specifically
only for a real shell, shouldn't they just be set that way?
cgf
___
Make-w32 mailing list
Make-w32@gnu.org
http://lists.gnu.org/mailman/listinfo/make-w32
Re: Fix for HAVE_DOS_PATHS build on cygwin
On Thu, Aug 17, 2006 at 10:23:35AM -0400, Bill Hoffman wrote: At 11:40 PM 8/16/2006, Christopher Faylor wrote: I don't understand why isn't this just using the UNIX-ish settings for Cygwin. The settings should, at the very least, be the same as the UNIX-sh case. Because there was a bug where sh_chars_sh was being directly referenced if HAVE_DOS_PATHS was on. I have a new patch. Yes, I got that. I didn't like the duplication of blocks of code, especially since it changed one of the tables from what is currently being used for Cygwin. diff -p make381orig/make-3.81/config.h.in make-3.81/config.h.in *** make381orig/make-3.81/config.h.in Sat Apr 1 01:40:00 2006 --- make-3.81/config.h.in Wed Aug 16 16:31:10 2006 *** *** 75,80 --- 75,84 /* Use platform specific coding */ #undef HAVE_DOS_PATHS + #ifdef __CYGWIN__ + #define HAVE_DOS_PATHS 1 + #endif + /* Define to 1 if you have the `dup2' function. */ #undef HAVE_DUP2 diff -p make381orig/make-3.81/job.c make-3.81/job.c *** make381orig/make-3.81/job.c Sun Mar 19 22:03:04 2006 --- make-3.81/job.c Thu Aug 17 10:06:24 2006 *** construct_command_argv_internal (char *l *** 2521,2527 #endif if (p[1] != '\\' p[1] != '\'' !isspace ((unsigned char)p[1]) !strchr (sh_chars_sh, p[1]) == 0) /* back up one notch, to copy the backslash */ --p; #endif /* HAVE_DOS_PATHS */ --- 2521,2527 #endif if (p[1] != '\\' p[1] != '\'' !isspace ((unsigned char)p[1]) !strchr (sh_chars, p[1]) == 0) /* back up one notch, to copy the backslash */ --p; I don't think this is right. The comment above this line refers to operations on Unixy shells. I think that just adding something like: #ifdef HAVE_DOS_PATHS static const char *sh_chars_sh = sh_chars; #endif in the #else /* must be UNIX-ish */ clause would probably handle this. #endif /* HAVE_DOS_PATHS */ diff -p make381orig/make-3.81/make.h make-3.81/make.h *** make381orig/make-3.81/make.hWed Feb 15 18:54:43 2006 --- make-3.81/make.hThu Aug 17 10:10:39 2006 *** extern int strcmpi (const char *,const c *** 347,353 #define S_(msg1,msg2,num) ngettext (msg1,msg2,num) /* Handle other OSs. */ ! #if defined(HAVE_DOS_PATHS) # define PATH_SEPARATOR_CHAR ';' #elif defined(VMS) # define PATH_SEPARATOR_CHAR ',' --- 347,353 #define S_(msg1,msg2,num) ngettext (msg1,msg2,num) /* Handle other OSs. */ ! #if defined(HAVE_DOS_PATHS) !defined(__CYGWIN__) # define PATH_SEPARATOR_CHAR ';' #elif defined(VMS) # define PATH_SEPARATOR_CHAR ',' This is probably too big a change for this particular problem (and maybe it's already been discussed to death) but I don't see why this setting couldn't be in configure.in, too. Then MinGW could set PATH_SEPARATOR_CHAR to ';', VMS could set it to ',' (shouldn't that be '.'?), and Cygwin and every other UNIX system could just use the default. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Fix for HAVE_DOS_PATHS build on cygwin
On Thu, Aug 17, 2006 at 12:38:29PM -0400, Bill Hoffman wrote: At 11:42 AM 8/17/2006, Christopher Faylor wrote: On Thu, Aug 17, 2006 at 10:23:35AM -0400, Bill Hoffman wrote: if (p[1] != '\\' p[1] != '\'' !isspace ((unsigned char)p[1]) !strchr (sh_chars, p[1]) == 0) /* back up one notch, to copy the backslash */ --p; I don't think this is right. The comment above this line refers to operations on Unixy shells. I think that just adding something like: #ifdef HAVE_DOS_PATHS static const char *sh_chars_sh = sh_chars; #endif in the #else /* must be UNIX-ish */ clause would probably handle this. That would work, but it sort of seems odd that sh_chars_sh would be directly referenced anywhere. It looks to me like sh_chars should be used in all places, so that sh_chars_sh and sh_chars_dos can be set at run time. I guess it is a style thing, but this is the only place sh_chars_sh is referenced outside of an initialization for sh_chars. So, it seemed out of place to me. Read the comment I mentioned. It explains why this is sh_chars_sh rather than sh_chars. It does make me wonder what kind of quoting problems we'd see with HAVE_DOS_PATHS, though. On cygwin, I wouldn't want every backslash to be interpreted as part of a path name just in case. /* Handle other OSs. */ ! #if defined(HAVE_DOS_PATHS) !defined(__CYGWIN__) # define PATH_SEPARATOR_CHAR ';' #elif defined(VMS) # define PATH_SEPARATOR_CHAR ',' This is probably too big a change for this particular problem (and maybe it's already been discussed to death) but I don't see why this setting couldn't be in configure.in, too. Then MinGW could set PATH_SEPARATOR_CHAR to ';', VMS could set it to ',' (shouldn't that be '.'?), and Cygwin and every other UNIX system could just use the default. Sure, this seems to produce the correct behavior. If you want to make it a configure.in thing, then provide a patch. I was just going along with the existing style of the code in this case. I'm not a make maintainer and don't really care about this one way or the other. I was just pointing out that I thought it made sense to do things this way. Personally, I think that things like #ifdef __OSNAME__ to code, should be avoided although I don't see a way around it in this case, if the current way of handling things is maintained. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Fix for HAVE_DOS_PATHS build on cygwin
On Thu, Aug 17, 2006 at 01:42:53PM -0400, Eli Zaretskii wrote: Date: Thu, 17 Aug 2006 12:38:29 -0400 From: Bill Hoffman [EMAIL PROTECTED] /* Handle other OSs. */ ! #if defined(HAVE_DOS_PATHS) !defined(__CYGWIN__) # define PATH_SEPARATOR_CHAR ';' #elif defined(VMS) # define PATH_SEPARATOR_CHAR ',' This is probably too big a change for this particular problem (and maybe it's already been discussed to death) but I don't see why this setting couldn't be in configure.in, too. Then MinGW could set PATH_SEPARATOR_CHAR to ';', VMS could set it to ',' (shouldn't that be '.'?), and Cygwin and every other UNIX system could just use the default. Sure, this seems to produce the correct behavior. If you want to make it a configure.in thing, then provide a patch. I was just going along with the existing style of the code in this case. The Cygwin build could (and probably should) use configure.in, but the MinGW and MSVC ports don't use the configure script to build themselves, and so the native builds cannot set PATH_SEPARATOR_CHAR there. Whatever the mechanism, it seems like this could easily be made part of config.h. Wouldn't just adding it to configh.dos suffice? cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Fix for HAVE_DOS_PATHS build on cygwin
On Thu, Aug 17, 2006 at 11:09:31PM +0300, Eli Zaretskii wrote: Date: Thu, 17 Aug 2006 13:50:49 -0400 From: Christopher Faylor [EMAIL PROTECTED] The Cygwin build could (and probably should) use configure.in, but the MinGW and MSVC ports don't use the configure script to build themselves, and so the native builds cannot set PATH_SEPARATOR_CHAR there. Whatever the mechanism, it seems like this could easily be made part of config.h. For the non-Cygwin ports, or for Cygwin as well? Wouldn't just adding it to configh.dos suffice? That one is for the DOS (a.k.a. DJGPP) port. The Windows ports use config.h.W32. Right. This is even easier than I was thinking, really. If this value was defined in the appropriate pre-header file then an #ifndef PATH_SEPARATOR # define PATH_SEPARATOR : #endif in make.h would suffice, wouldn't it? So, I guess I'm basically suggesting putting the PATH_SEPARATOR definition in: config.h-vms, config.h.W32, configh.dos. But, I dunno, maybe it's just overkill. I was just trying to avoid a spurious #ifdef test. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Fix for HAVE_DOS_PATHS build on cygwin
On Thu, Aug 17, 2006 at 11:30:53PM +0300, Eli Zaretskii wrote: Date: Thu, 17 Aug 2006 15:50:11 -0400 From: Bill Hoffman [EMAIL PROTECTED] I'm not a make maintainer and don't really care about this one way or the other. [...] I am not a make maintainer either, and care even less than you. Sorry, Bill, you lost me here: I thought you _did_ care about this, since you submitted the patch and evidently did some testing, enough to find a couple more issues that needed to be solved. For the record, my not caring was just really an indication that I wasn't going to argue vehemently about it with you, Eli, or anyone else. I was just flagging the issue. But, I suspect you know that, already. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Fix for HAVE_DOS_PATHS build on cygwin
On Thu, Aug 17, 2006 at 04:56:03PM -0400, Paul D. Smith wrote: Please don't dispair if I'm not as communicative as I usually am. For those not aware, in the real world I've decided to leave my previous position (of 13+ years!) and take on a new challenge. As a result, there is some turbulence in my life at the moment and one consequence of this is I've not gotten my email situation ironed out completely to my satisfaction... this means I'm not reading email as consistently as I'd like. Good luck in your new position. One thing: my original idea was to have a configure option that enabled the DOS path capabilities. I note some here are advocating a configure test which simply sets the HAVE_DOS_PATHS option if Cygwin is detected, rather than leaving it up to the user. Is it the case that people might want to build a Cygwin version of make _WITHOUT_ DOS path support? Something to think about anyway. I'm all for flexibility. I suspect that this will have to be the default for cygwin, however, or we will hear wails of despair from any brave soul who tries to build from source. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Fix for HAVE_DOS_PATHS build on cygwin
On Thu, Aug 17, 2006 at 11:41:01PM +0300, Eli Zaretskii wrote: Date: Thu, 17 Aug 2006 13:21:31 -0400 From: Christopher Faylor [EMAIL PROTECTED] Cc: It does make me wonder what kind of quoting problems we'd see with HAVE_DOS_PATHS, though. On cygwin, I wouldn't want every backslash to be interpreted as part of a path name just in case. If we want the Cygwin port to support c:\foo\bar, there's no other way I know of. If the Cygwin port should support only c:/foo/bar, then that particular code fragment should be ifdef'ed away for Cygwin. What is best should be decided by the Cygwin community, so you may wish to discuss this on the Cygwin list. (If it matters, my advice would be to allow only the forward slashes for the Cygwin port, as it gives enough rope to get things done for minimal risk, and because backslashes are not 100% supported even in the native builds.) Whatever the decision, this is precisely the reason why the patch we eventually decide upon should be tested with as many Cygwin Makefile's as possible. I guess my concern is that there will be times where a '\' will not be interpreted as a quoting character when it really should be. I can't think of any examples, though. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: mingw make problems
On Fri, Aug 18, 2006 at 12:21:41AM +0300, Eli Zaretskii wrote: Date: Thu, 17 Aug 2006 17:02:30 -0400 From: Bill Hoffman At 04:48 PM 8/17/2006, Christopher Faylor wrote: I don't understand why MinGW's make should be using anything like /bin/sh. Shouldn't it be using cmd.exe or command.com? It seems that if it finds sh.exe in the path it uses it. Yes. This is by design (not mine, long before I started using the Windows port, let alone contributing to it). I'm guessing that the reason was twofold: (1) relative stupidity of Windows shells of yore, and (2) lots of Makefile's out there which depend on a Unixy shell, but don't say SHELL = /bin/sh explicitly. Make 3.81 adds a feature whereby you can say SHELL = cmd.exe and have it use CMD even if sh.exe is on your PATH. Previous versions of Make didn't allow even that. This behavior was controlled under the old Cygwin make via a --win32 option (an option that RMS repeatedly asked me to change, FWIW). So, it sounds like one solution to the problem might be to just use SHELL=cmd.exe. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
Re: Fix for HAVE_DOS_PATHS build on cygwin
On Fri, Aug 18, 2006 at 12:34:16AM +0300, Eli Zaretskii wrote: Date: Thu, 17 Aug 2006 17:30:50 -0400 From: Christopher Faylor [EMAIL PROTECTED] Cc: One thing: my original idea was to have a configure option that enabled the DOS path capabilities. I note some here are advocating a configure test which simply sets the HAVE_DOS_PATHS option if Cygwin is detected, rather than leaving it up to the user. Is it the case that people might want to build a Cygwin version of make _WITHOUT_ DOS path support? Something to think about anyway. I'm all for flexibility. I suspect that this will have to be the default for cygwin, however, or we will hear wails of despair from any brave soul who tries to build from source. 100% agreement. The less obscure switches with hard-to-explain effects, the less FAQs asked on the various mailing lists. We should introduce such a switch only if we cannot avoid it (i.e. if supporting DOS file names breaks something very valuable in the Cygwin version). I'm not sure if this is what you're saying but I wouldn't mind an option but only if (and I can't believe I'm saying this) the default is --with-dos-paths rather than --without-dos-paths. cgf ___ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
