make-w32
[Top][All Lists]
Advanced

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

Re: Problems with $(shell xxx) using uWin


From: James Kanze
Subject: Re: Problems with $(shell xxx) using uWin
Date: Sat, 03 Jun 2006 23:06:03 +0200
User-agent: Thunderbird 1.5.0.4 (X11/20060516)

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:

>   http://gnuwin32.sourceforge.net/

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

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

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

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

>   http://www.mingw.org/

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

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

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.

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

   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?

Binary.

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

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.

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

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

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

Anyhow, simple code review has shown me part of the problem with
pwd, at least.  The file is a readable shell script, designed to
work in the UWin environment (which remaps parts of the file
system so it looks like Unix, e.g. /bin specifies in fact
C:\UWIN\bin).  In the function process_begin in
w32/subproc/sub_proc.c, the system tries to find the file, open
it, determine if it is a shell script, and if so, it uses the
name given there as the name/path of the shell to be used.  And
when it tries to find the program "/bin/sh" using Windows system
requests, it will fail.
The UWin Korn shell does things this way, of course, so that
Unix shell scripts will work unchanged under it.  The obvious
solution in this case would be for make to systematically use
`$SHELL -c "..."' whenever it wanted a subprocess.  But there
are conflicting requirements involved here, and I'm pretty sure
that the solution adopted in sub_proc.c was done so for a
reason.  (And of course, not everyone using GNU make on Windows
is using UWin.)

It's getting late here, and I want to think about all of the
possible consequences before I start modifying the sources to
solve just my problem, so I won't attack it immediately.
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: http://kanze.james.free.fr, for
those interested.  The actual makefiles causing me the problems
are in the code tree.)

--
James Kanze                                    address@hidden
Conseils en informatique orientée objet/
                 Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34






reply via email to

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