[Please don't take this discussion off the mailing list.] > Date: Sat, 03 Jun 2006 20:26:08 +0200 > From: James Kanze <[EMAIL PROTECTED]> > > > I don't have UWIN installed, so I need more help from you to > > try to find out what could go wrong. > > Well, I didn't either, but CygWin doesn't handle remote files, > MKS is awfully expensive, and I come from a Unix environment. > My make files make extensive use of Unix commands, so I need a > Unix environment.
You can find native Windows ports of most everything in the GnuWin32 project's archives: http://gnuwin32.sourceforge.net/ The development environment (GCC, assembler, linker, debugger, etc.) can be found on the MinGW site: http://www.mingw.org/ These two sites is where I got most of my Unix tools. > I do, but the problem is independant of the command. I get the > similar results with e.g. $(shell ls *.cc), for example. Then I think something is very wrong with your shell. What happens if you add this line to your Makefile: SHELL = cmd.exe If it causes $(shell ls *.cc) to work, then the UWIN port of shell is the primary suspect. Btw, is `ls' a .exe program, or is it also a shell script? Actually, looking at the pwd script: > #! /bin/sh > typeset -l command=${00##*/} > command=${command/%+(.)} > "$command" "$@" am I imagining things or does it indeed run "command /c pwd"? If not, what does this script do, exactly? (I'm sorry, I never used Korn shell.) > Note that the version of GNU make delivered with CygWin does not > have this problem, when invoked on the exact same project > makefiles. Rumour has it that the Cygwin port of Make has private changes to the official Make code, and even if it doesn't, that's a different port built with different libraries. > It doesn't find files on remote mounted file > systems, however -- I suspect that this is a bug in the CygWin > layer, and not in make, since most of the other programs in > CygWin have this problem, at least sometimes. Cygwin problems are best discussed on the Cygwin mailing list. AFAIK, Cygwin maintainers don't read the make-w32 list, since the latter is for native Windows ports, not for Cygwin ports. > The problem is > either due to something I did wrong in the installation, or > something particular in the UWin environment, or a regression > error -- the version of make under CygWin is 3.80, where as I've > built and installed 3.81. Or CygWin compiled GNU make as a Unix > program, using their interface layer, and the problem is > somewhere in the windows interface code. If the problem is the Windows interface code in Make, then it doesn't happen with other ports of a Unix shell, or at least no one reported it until now. > > That said, there are some tricky details in how the Windows port of > > Make searches for external commands, and my questions above are meant > > to figure out what did the code do on your system (alternatively, step > > with a debugger into the function process_begin, defined on > > w32/subproc/sub_proc.c, and see what it does in your case). > > That's what I'm going to have to figure out how to do. The > problem is that I develope under Unix; I barely know enough > Windows to invoke the compiler from the command line, and I > don't know how to go about invoking the debugger on it; as far > as I know, there is no command line debugger under Windows, and > I'd have to create a project, or something like that, in Visual > Studios. How did you compile Make? what compiler did you use? Every development environment that has a compiler has a debugger to go with that compiler. > Also, I've never seen this sort of pop-up on earlier versions of > Windows. In Windows NT or Windows 2000, I've always gotten a > pop-up asking if I wanted to enter the debugger. This difference is immaterial: Windows just changed some of its behavior between the older versions and XP. _______________________________________________ Make-w32 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/make-w32
