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: Eli Zaretskii
Subject: Re: Problems with $(shell xxx) using uWin
Date: Sun, 04 Jun 2006 22:22:55 +0300

> Date: Sat, 03 Jun 2006 23:06:03 +0200
> From: James Kanze <address@hidden>
> Cc: address@hidden
> 
>  >   http://gnuwin32.sourceforge.net/
> 
> Thanks.  But make doesn't seem to be there.

You already have Make, the one you compiled with MSVC.

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

There are some native ports of a Unixy shell out there.  I use a
ported zsh, and it works well enough for running Makefiles and
not-too-complex shell scripts.

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

I'm quite sure the problem is not in how you built Make.

> 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 doubt that a MinGW build would change anything: it's a different
compiler, but it compiles the same source code as MSVC (apart from
insignificant syntax-related issues), and the produced binary uses the
same runtime as the MinGW build.

One thing to try is to change the optimization level.  build_w32.bat
supports a ``Debug'' build and a ``Release'' build.  Whichever of them
you produced, try the other one, and see if the problem goes away.

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

We may have different goals here.  My goal is to try to fix bugs in
the native Windows (MinGW and MSVC) builds of Make, while yours is to
have your code build with a minimal effort.

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

That probably means Make crashes either on exit or when $shell
returns.

Are you saying that Make generally works, except when you use $shell?
If so, then unless you can debug the problem on your machine, a
workaround would be to refrain from using $shell.  For example,
$(shell pwd) can be replaced by $(CURDIR).

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

Yes, it was.

> 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 are definitely not the first; I do it as well, and many others
too.  I just don't use UWIN.  (Looked at it, saw that it required a
runtime DLL and came with a whole slew of UWIN-specific ports, and got
turned off.  I don't like packages that ask you to marry them for
life and that don't run natively, which means won't work well with
native programs.  But that's me.)

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

You got it almost right, but the last sentence is wrong: sub_proc.c
doesn't look for "/bin/sh", it looks for just "sh":

                        /*
                         *  Find base name of shell
                         */
                        shell_name = strrchr( buf, '/');
                        if (shell_name) {
                                shell_name++;
and later:
                command_line = make_command_line( shell_name, 
file_info.szPathName,
                                 argv);

The result of all this is clearly seen in the transcript you posted:

> >>     CreateProcess(NULL,sh C:\UWIN\usr\bin\pwd,...)

which shows that CreateProcess invokes the command
"sh C:\UWIN\usr\bin\pwd".  If sh.exe is on your PATH, it will be found
and invoked.  And your transcript shows that the shell actually _is_
found, as this message comes from the shell:

> >>     /C/UWIN\usr\bin\pwd: line 4: uwin\usr\bin\pwd: not found

Except that it fails to run pwd, probably because it cannot cope with
mixed forward- and back-slashes in file names, or for some other
reason.

So it looks like sub_proc.c works as intended in your case, and the
reason for the crash is elsewhere, either in some other place in the
code, or in the environment created by the UWIN port of the shell.




reply via email to

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