On 2006-5-7 19:07 UTC, Eli Zaretskii wrote:
>
> Using SHELL from the environment would be against the practice on
> Unix. And using COMSPEC if SHELL is undefined will effectively make
> cmd.exe the default shell (because most users don't have SHELL in the
> environment). That is a major change i
Quoting Eli Zaretskii <[EMAIL PROTECTED]>:
Date: Sun, 07 May 2006 11:45:26 -0400
From: Earnie Boyd <[EMAIL PROTECTED]>
Quoting Eli Zaretskii <[EMAIL PROTECTED]>:
> looking for sh.exe along the PATH, which is quite close. What do you
> suggest to do instead? use cmd.exe?
>
If enviroment varia
> The question here is: What should the Windows port use as the default
> shell if the Makefile doesn't specify any value for SHELL? The Posix
> version uses /bin/sh as the default, but on Windows this name will not
> work, in general. The current code emulates this Posix feature by
> looking for
> Date: Sun, 07 May 2006 11:45:26 -0400
> From: Earnie Boyd <[EMAIL PROTECTED]>
>
> Quoting Eli Zaretskii <[EMAIL PROTECTED]>:
>
> > looking for sh.exe along the PATH, which is quite close. What do you
> > suggest to do instead? use cmd.exe?
> >
>
> If enviroment variable SHELL exists use its v
Quoting Eli Zaretskii <[EMAIL PROTECTED]>:
looking for sh.exe along the PATH, which is quite close. What do you
suggest to do instead? use cmd.exe?
If enviroment variable SHELL exists use its value otherwise use the
value of COMSPEC unless the makefile sets SHELL explicitly.
Earnie Boyd
> From: "grischka" <[EMAIL PROTECTED]>
> Date: Sat, 6 May 2006 16:32:05 +0200
>
> > > Also what I vote for is to remove the dependency of $(SHELL) on
> > > the PATH setting on the user's computer.
>
> > I'm not sure I understand; can you elaborate?
>
> GNU make docs write:
>
> > Unlike most var
-- Eli Zaretskii wrote:
> The problem is, even if the shell runs a .exe program, and that
> program fails, the Windows 9x shell doesn't return the failing exit
> status, it always returns zero. And in those cases, you _do_ care
> about the true exit status, because you want Make to know about the
> From: "grischka" <[EMAIL PROTECTED]>
> Date: Thu, 4 May 2006 17:54:07 +0200
>
> I was going to think I dont really care for exitcodes from shell
> commands like 'echo' or 'type', not even that I would use these.
> Maybe just 'del' for 'clean:' targets to keep makefiles working
> for people who d
Eli Zaretskii <[EMAIL PROTECTED]> wrote:
> ...
> I added a
> fragment to explicitly stop the main thread while the signal handler
> runs, to emulate the Posix behavior, without which the two threads
> will step on each others' toes.
Works fine here. I tried up to -j9, no problems so far.
> If we
> Date: Tue, 2 May 2006 16:01:36 -0400
> Cc: "grischka" <[EMAIL PROTECTED]>, make-w32@gnu.org
> From: "Paul D. Smith" <[EMAIL PROTECTED]>
>
> Since "T2" was already tried (and failed) during the "reading makefiles"
> phase, and then the error was ignored... it's not clear exactly how this
> should
Quoting Eli Zaretskii <[EMAIL PROTECTED]>:
Well, I'd say this is probably a bug in rxvt.
Yes, and not likely to be fixed anytime soon. To workaround ``start
/msys --norxvt''.
Earnie Boyd
http://shop.siebunlimited.com
___
Make-w32 mailing li
%% Eli Zaretskii <[EMAIL PROTECTED]> writes:
>> - makefile
>> all: T1 T2
>> T1:; exit 101
>> T2:; exit 202
>> -include T2
>> - make 3.81.90:
>> exit 202
>> exit 101
>> ~make: *** [T1] Error 101
ez> Paul, is this true that there has been a change in behavior in
ez> t
> From: "grischka" <[EMAIL PROTECTED]>
> Date: Tue, 2 May 2006 16:12:08 +0200
>
> The one seems indeed a change in make behaviour whether or not
> it stops when the -include target cannot be made. Example:
>
> - makefile
> all: T1 T2
> T1:
> exit 101
> T2:
> exit 202
>
> -include T2
>
> I could never reproduce that problem. Someone else said that they
> could reproduce it, and tried to debug it, but I don't know whether it
> was finished.
I believe he had seen two diffent things.
The one seems indeed a change in make behaviour whether or not
it
> From: "grischka" <[EMAIL PROTECTED]>
> Date: Mon, 1 May 2006 00:23:07 +0200
>
> There was a similar topic here previously, that on windows make does
> not stop after errors or sometimes goes into "background" and still for
> a while outputs some messages.
I could never reproduce that problem.
There was a similar topic here previously, that on windows make does
not stop after errors or sometimes goes into "background" and still for
a while outputs some messages.
That happens to me when I:
1) have quotes on the line, e.g:
gcc -D "VERSION=\"1.2.3\"" ...
2) dont have sh.exe in the
16 matches
Mail list logo
