Re: Problems with $(shell xxx) using uWin

[Eli Zaretskii]

[Please don't take this discussion off the mailing list.]

> Date: Sat, 03 Jun 2006 20:26:08 +0200
> From: James Kanze <address@hidden>
> 
>  > 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.