On 26/10/2007, Earnie Boyd <[EMAIL PROTECTED]> wrote:
> Quoting grischka <[EMAIL PROTECTED]>:
>
> > Earnie Boyd wrote:
> >
> >> >make CVS as is :
> >> >7.09 seconds
> >> >
> >> > make CVS with per command path search :
> >> >2.81 seconds
> >> >
> >> > Surprised?
> >>
> >
Earnie Boyd wrote:
> >make CVS as is :
> >7.09 seconds
> >
> > make CVS with per command path search :
> >2.81 seconds
> >
> > Surprised?
>
> No, you didn't reboot first.
>
> Earnie
Is this serious or a joke?
If serious: No, both from cache. No disk activity involve
> > From: "Dave Korn"
> >
> >> Ummm, that doesn't really sound like a well thought through plan
> >> to me.
> >
> > That only means it can still happen.
>
> Yes, but it suggests something about /how/ it should happen: it should be
> designed and spec'd before it is implemented. That's just ele
Quoting grischka <[EMAIL PROTECTED]>:
Earnie Boyd wrote:
>make CVS as is :
>7.09 seconds
>
> make CVS with per command path search :
>2.81 seconds
>
> Surprised?
No, you didn't reboot first.
Earnie
Is this serious or a joke?
If serious: No, both from cache. No d
On 24 October 2007 00:39, grischka wrote:
> From: "Dave Korn"
>
>> Ummm, that doesn't really sound like a well thought through plan
>> to me.
>
> That only means it can still happen.
Yes, but it suggests something about /how/ it should happen: it should be
designed and spec'd before it is imp
Quoting grischka <[EMAIL PROTECTED]>:
make CVS as is :
7.09 seconds
make CVS with per command path search :
2.81 seconds
Surprised?
No, you didn't reboot first.
Earnie
___
Make-w32 mailing list
Make-w32@gnu.org
http://lists.gnu.org/mail
From: "Dave Korn"
> Ummm, that doesn't really sound like a well thought through plan
> to me.
That only means it can still happen.
> Well, this is something that is easily amenable to testing and measurement.
> It would be pretty trival to add a call to a path search (even one that is
> just
Eli Zaretskii wrote:
> > > That'd be a terrible
> > > cycle killer, because this function would be called on each command
> > > invocation.
> >
> > But no. Compared to what it takes the OS to spawn (and run!) a process,
> > one path search more or less wont make even the slightest difference.
>
>
On Oct 22, 2007, at 11:06 PM, Eli Zaretskii wrote:
That'd be a terrible
cycle killer, because this function would be called on each command
invocation.
But no. Compared to what it takes the OS to spawn (and run!) a
process,
one path search more or less wont make even the slightest differenc
On 22 October 2007 16:01, grischka wrote:
> Eli Zaretskii wrote:
>> I'm not sure I follow: are you suggesting to write a function named
>> w32_adjust_shell_and_set_mode_flags
>
> Yes, a function that operates on the expanded string of SHELL
> when it's about to be used.
>
>> that would search fo
> From: "grischka" <[EMAIL PROTECTED]>
> Cc:
> Date: Mon, 22 Oct 2007 17:00:48 +0200
>
> > That'd be a terrible
> > cycle killer, because this function would be called on each command
> > invocation.
>
> But no. Compared to what it takes the OS to spawn (and run!) a process,
> one path search m
> Date: Mon, 22 Oct 2007 12:56:21 +0800
> From: "Yongwei Wu" <[EMAIL PROTECTED]>
> Cc: "Eli Zaretskii" <[EMAIL PROTECTED]>, make-w32@gnu.org
>
> On 21/10/2007, grischka <[EMAIL PROTECTED]> wrote:
> > We can initialize SHELL either fixed to COMSPEC, or fixed to "sh",
> > optionally from the environ
Eli Zaretskii wrote:
> I'm not sure I follow: are you suggesting to write a function named
> w32_adjust_shell_and_set_mode_flags
Yes, a function that operates on the expanded string of SHELL
when it's about to be used.
> that would search for SHELL along
> PATH, like find_and_set_default_shell d
Quoting Yongwei Wu <[EMAIL PROTECTED]>:
On 21/10/2007, grischka <[EMAIL PROTECTED]> wrote:
We can initialize SHELL either fixed to COMSPEC, or fixed to "sh",
optionally from the environment (SHELL or MAKESHELL), or based on PATH
search as currently (which I think is evil, though).
As 'default
On 21/10/2007, grischka <[EMAIL PROTECTED]> wrote:
> We can initialize SHELL either fixed to COMSPEC, or fixed to "sh",
> optionally from the environment (SHELL or MAKESHELL), or based on PATH
> search as currently (which I think is evil, though).
>
> As 'default shell' on windows is a political qu
> From: "grischka" <[EMAIL PROTECTED]>
> Cc:
> Date: Sun, 21 Oct 2007 14:25:14 +0200
>
> > Please suggest another way, if you can. Whenever Make wants to use
> > the shell, it does this:
> >
> > shell = allocated_variable_expand_for_file ("$(SHELL)", file);
> >
> > That is, it simply looks a
> > $ type makefile
> > SHELL = test.bat
> > all : ; @echo "$(SHELL)"
> >
> > $ gmake
> > "c:/tools/test.bat"
> >
> > Obviously gmake resolves "test.bat" from my PATH which is wrong in
> > so far as no variable is supposed to change the value on its own.
>
> Please suggest anoth
> From: "grischka" <[EMAIL PROTECTED]>
> Cc:
> Date: Sat, 20 Oct 2007 17:08:38 +0200
>
> $ type makefile
> SHELL = test.bat
> all : ; @echo "$(SHELL)"
>
> $ gmake
> "c:/tools/test.bat"
>
> Obviously gmake resolves "test.bat" from my PATH which is wrong in
> so far as no var
Eli Zaretskii wrote:
> I always wonder why people feel a need to post such derogatory
> comments. Is there some kind of satisfaction in it?
What do you expect? That is the nature of feedback. If it's all
well it mostly wont happen.
> I'm not sure it should be documented: the Windows port just be
> Date: Fri, 19 Oct 2007 14:51:23 -0700
> From: Tom Honermann <[EMAIL PROTECTED]>
> CC: make-w32@gnu.org
>
> I think there is a difference in behavior here. On a UNIX system if
> '/bin/sh' were to be missing, Make would still attempt to exec
> '/bin/sh' and then would report the error. However,
Eli Zaretskii wrote:
I don't know who benefits from it but so far nobody dared to
document it, either.
I'm not sure it should be documented: the Windows port just behaves
the same as the Unix original. Here's the relevant fragment executed
by Make on Unix (job.c, around line 2100):
# if
> From: "grischka" <[EMAIL PROTECTED]>
> Date: Fri, 19 Oct 2007 19:55:54 +0200
> Cc: make-w32@gnu.org
>
> It is one of gmake's undocumented non-features with SHELL on
> windows.
I always wonder why people feel a need to post such derogatory
comments. Is there some kind of satisfaction in it?
>
Gary Turner wrote:
> It all worked perfectly until I installed a compiler that put a sh
> shell on my path. Since then all my makefiles are broken.
It is one of gmake's undocumented non-features with SHELL on
windows. I don't know who benefits from it but so far nobody
dared to document it, e
> Date: Fri, 19 Oct 2007 07:28:31 -0400
> From: Earnie Boyd <[EMAIL PROTECTED]>
>
> > Make appears to insist on using the sh shell buried on my path rather
> > than cmd.exe
> > I've tried explicitly putting SHELL = cmd.exe in my makefiles - but
> > that didn't seem to work. Putting SHELL = c:\wi
> -Original Message-
> From: make-w32-bounces On Behalf Of Earnie Boyd
> Quoting Gary Turner <[EMAIL PROTECTED]>:
> > It all worked perfectly until I installed a compiler that put a sh
> > shell on my path. Since then all my makefiles are broken.
> Bad business. Is there a reason the c
> Date: Fri, 19 Oct 2007 14:05:23 +1300
> From: Gary Turner <[EMAIL PROTECTED]>
>
> It all worked perfectly until I installed a compiler that put a sh shell
> on my path. Since then all my makefiles are broken.
If your makefiles use features specific to cmd.exe, and don't specify
SHELL = cmd.exe,
Quoting Gary Turner <[EMAIL PROTECTED]>:
It all worked perfectly until I installed a compiler that put a sh
shell on my path. Since then all my makefiles are broken.
Bad business. Is there a reason the compiler needs the PATH set?
Make appears to insist on using the sh shell buried on my
I've used make on windows for quite a while - I use it for all sorts of
non-compilation tasks, and my makefiles tend to occasionally use dos-type
commands - e.g if exist ...
It all worked perfectly until I installed a compiler that put a sh shell on my
path. Since then all my makefiles are brok
28 matches
Mail list logo
