[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with $(shell xxx) using uWin

From: Earnie Boyd
Subject: Re: Problems with $(shell xxx) using uWin
Date: Sun, 04 Jun 2006 10:05:25 -0400
User-agent: Internet Messaging Program (IMP) H3 (4.0.4)

Quoting James Kanze <address@hidden>:

Eli Zaretskii wrote:
> [Please don't take this discussion off the mailing list.]

Sorry.  I didn't do it intentionnally.

>> 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:


Thanks.  But make doesn't seem to be there.  Nor bash, for that
matter.  Both UWin and CygWin (and MKS, if you can afford it)
provide fully integrated, complete environments.  My make files
(and my way of working) depend on a full Unix environment,
including a Unix like shell.  (I've not intentionally used
anything that wouldn't work in a Bourne shell, but I usually use
either bash or ksh myself.)

You forgot to mention MSYS. :)

(If make had been present, I would have downloaded their
version.  I'm still not really sure that the problem doesn't
come from something I did in building it.)

It wouldn't have solved your problem anyway.

CygWin comes with GNU make -- my makefiles, and everything else,
work perfectly with it.  As long as the files are local.

And has been stated already Cygwin's make has local modifications that are not part of the official source. It also uses the Cygwin runtime so there is more control of the stdio than with the ``native'' version executed from with Cygwin. So what exactly can't the Cygwin make do? [OT for this list, let's discuss privately.]

The developement tools for UWin are in a separate package, and
the make is a Bell Labs make, not GNU make.  Over the time, I've
gradually moved to GNU make completely, using many, many of its
extensions.  And I'm used to having to install it separately; it

Doesn't UWin also have an emulation runtime that is used? My guess is that it doesn't know how to control the make jobs correctly.

doesn't come with Solaris either.  This is the first time I've
had any problem.  (Of course, it's also the first time I've
tried to do it on a system I'm not really that familiar with.)

> The development environment (GCC, assembler, linker, debugger,
> etc.) can be found on the MinGW site:


This is where MSYS lives as well.

> These two sites is where I got most of my Unix tools.

One of the requirements in moving the code to Windows is that it
must compile with Visual C++.  (On the other hand, MinGW might
be a good choice for compiling make.)

It works, you can even use configure to create the Makefile.

>> 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

Even without trying it...  It will cause no end of problems in
my real makefiles.  For some rules, the actions are decidely
non-trivial shell scripts, embedded in the makefile.

But that is what the ``native'' version of make will use if sh.exe isn't on your PATH. Does UWin come with a developers library to allow you to build the make dependent on the UWin runtime? I think that is the only way to resolve your issue.

My real problem is simply: I have a significant body of code
developped under Unix (Solaris, mainly), with a build system
based on a fairly advanced use of GNU make.  I am trying to port
it to Windows, while doing the least amount of work possible.

This is what MinGW/MSYS is about. So is Cygwin if you can live with the slowness of the emulation library. If you're trying to build native versions then MinGW/MSYS is probably your better choice; a prejudiced remark I'm sure.

> If it causes $(shell ls *.cc) to work, then the UWIN port of
> shell is the primary suspect.

I still get the funny pop-up.  The output of make -d is now:

   GNU Make 3.81
   Copyright (C) 2006  Free Software Foundation, Inc.
   This is free software; see the source for copying conditions.
   There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A

   This program built for Windows32
   find_and_set_shell path search set default_shell = C:/UWIN/usr/bin/sh.exe
   Reading makefiles...
   Reading makefile `GNUmakefile'...
   find_and_set_shell setting default_shell = cmd.exe
   CreateProcess(C:\UWIN\usr\bin\ls.exe,ls *.cc,...)
   ls: *.cc: not found

One extra line, which looks like ls was actually executed.

> 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.)

I've never done anything that exotic either.  For portability
reasons, I try to restrict myself to standard Bourn shell in
scripts.  And there are several things I don't understand in the

The script is trying to ensure that the builtin pwd is being executed. The ``typeset -l'' converts all of the characters to lowercase the ${00##*/} removes the directory portion from the command and I think the ${command/%+(.)} is stripping of any extenstion. *I think* because when I tried it with the MSYS shell (I created an that executed all but the typeset command on itself) it the string function didn't actually remove the .sh.

If I do "type pwd" in the shell, it says that pwd is a shell
builtin; it actually surprised me to find an executable file
with that name.

This is often the case and is done for portability. Not all shells have a builtin pwd.

>> 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.

I realize that.  The different libraries part; I hadn't heard
about the private changes.  But from what little I have heard
about CygWin, they use the Unix version of the code, and then
map using their special libraries.

Well, it's a POSIX emulation runtime.

>> 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.

Agreed.  I just mentionned it in passing, to explain why I was
trying to get a native port working.

>> 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.

Well, I'm certainly not the first to use the native Windows
port.  On the other hand, while it would surprise me somewhat, I
suppose I could be the first to use $(shell...) in the UWin
environment (with a non-standard -- for Windows -- command processor).

You'll probably find more people using Cygwin or MSYS than UWin.

>>  > 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.

I used Visual Studios 2005.  But all I did to build make was
invoke build_w32.bat from a command line.  The Visual Studios
documentation does explain how to invoke the compiler from the
command line -- it even gives considerable information about how
to set up your environment variables in order to do so.  I've
not found any comparable documentation for invoking the
debugger.  Of course, I've not looked, but there is a major
difference: the compiler doesn't manage multiple windows, etc.;
the debugger does.

I still think it is the runtime issue. Note that Cygwin and MSYS have an issue as well with executing the ``native'' make within it's environment.


FWIW: the basic problem is that I am making my C++ library
sources available Open Source.  And since Windows isn't going to
disappear, I feel that, responsibly, they should be usable there
as well.  By a normal Windows programmer:-).  Requiring him to
install CygWin or UWin+GNU make is already pushing it; requiring
him to manually patch the sources, then compile them from the
command line, is definitly too much.  (For information: the site
with the sources is already up:, for
those interested.  The actual makefiles causing me the problems
are in the code tree.)

Please consider using MinGW and MSYS. We try to keep it small for this reason.

Earnie Boyd

reply via email to

[Prev in Thread] Current Thread [Next in Thread]