On 04/10/2007, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 03 October 2007 17:01, Yongwei Wu wrote:
>
>
> >> The only real solution is to avoid alloca() and use malloc() everywhere.
> >
> > I do not like heap allocation here, which is vastly slower, and will
> > really make the Windows fix very, very
On 04/10/2007, Paul Smith <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-10-03 at 21:44 +0200, Eli Zaretskii wrote:
> > Maybe we should simply have a wrapper for `stat' on Windows, which
> > could remove the slashes. Then these problems would be solved in one
> > place once and for all.
>
> I was think
On Wed, 2007-10-03 at 21:44 +0200, Eli Zaretskii wrote:
> Maybe we should simply have a wrapper for `stat' on Windows, which
> could remove the slashes. Then these problems would be solved in one
> place once and for all.
I was thinking about this today. It seems like it would be a useful
thing
On Wed, 2007-10-03 at 17:26 +0100, Dave Korn wrote:
> "Slow" is a relative term. Given that this allocation is only
> necessary when we're about to go out to the disk to perform a 'stat'
> operation, I believe that the (actually fairly small) amount of time
> it takes the heap allocater to pull a
> From: "grischka" <[EMAIL PROTECTED]>
> Date: Wed, 3 Oct 2007 20:20:08 +0200
> Cc: make-w32@gnu.org
>
> > And I have tested that neither DIR\\ or DIR/ can match an
> > existing directory DIR currently---removing the trailing slash is OK.
>
> This is probably because there are some more stat()'s
> Can we make sure all arguments passed to find_directory on Windows
> do not contain a "/" or "\" at the end? I cannot find any example
> either.
Try this:
VPATH = foo\ bar
all : zap.o
Note that normally (like with: foo\ bar:;echo $@) foo\ bar
is one filename with a space, i.e. "foo bar", b
On 03 October 2007 17:01, Yongwei Wu wrote:
>> The only real solution is to avoid alloca() and use malloc() everywhere.
>
> I do not like heap allocation here, which is vastly slower, and will
> really make the Windows fix very, very ugly.
"Slow" is a relative term. Given that this allocatio
On 03/10/2007, Paul Smith <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-10-03 at 14:31 +0200, Eli Zaretskii wrote:
> > To be on the safe side with this issue, we really need to call
> > pathconf to get the correct values. (It will need to be emulated on
> > Windows, but that isn't hard, at least as fa
> Date: Wed, 3 Oct 2007 21:16:31 +0800
> From: "Yongwei Wu" <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], make-w32@gnu.org
>
> > > I was frustrated by the fact that Batch files do not support things
> > > like "echo -n" and "`cmd`", so resorting to a Shell script was really
> > > a desperate hack.
On Wed, 2007-10-03 at 14:31 +0200, Eli Zaretskii wrote:
> To be on the safe side with this issue, we really need to call
> pathconf to get the correct values. (It will need to be emulated on
> Windows, but that isn't hard, at least as far as _POSIX_PATH_MAX and
> _POSIX_NAME_MAX are concerned.) I
On 03/10/2007, Eli Zaretskii <[EMAIL PROTECTED]> wrote:
> > Date: Wed, 3 Oct 2007 09:53:43 +0800
> > From: "Yongwei Wu" <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED], make-w32@gnu.org
> >
> > > +if exist config.h.W32 GoTo NotCVS
> > > +sed -n "s/^AC_INIT(\[GNU make\],\[\([^]]\+\)\].*/s,%%VERSION%%,
> Date: Wed, 03 Oct 2007 07:49:39 -0400
> From: Earnie Boyd <[EMAIL PROTECTED]>
>
> > This doesn't seem to be as much of an issue on Windows where the max
> > path length appears to be much more strictly defined.
> >
>
> I wouldn't count on that as always going to be.
To be on the safe side with
> Date: Wed, 3 Oct 2007 19:26:29 +0800
> From: "Yongwei Wu" <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], make-w32@gnu.org
>
> On 03/10/2007, Eli Zaretskii <[EMAIL PROTECTED]> wrote:
> > > From: Paul Smith <[EMAIL PROTECTED]>
> > > Cc: Yongwei Wu <[EMAIL PROTECTED]>, make-w32@gnu.org
> > > Date: Tu
Quoting Eli Zaretskii <[EMAIL PROTECTED]>:
Date: Tue, 02 Oct 2007 14:11:07 -0400
From: Earnie Boyd <[EMAIL PROTECTED]>
I think you need both. I don't build with WINDOWS. I build with UNIXY
SHELL on WINDOWS.
But then you don't need config.h.W32.template, do you? You run the
configure scrip
Quoting Paul Smith <[EMAIL PROTECTED]>:
This doesn't seem to be as much of an issue on Windows where the max
path length appears to be much more strictly defined.
I wouldn't count on that as always going to be.
Earnie
___
Make-w32 mailing list
Quoting Yongwei Wu <[EMAIL PROTECTED]>:
On 03/10/2007, Eli Zaretskii <[EMAIL PROTECTED]> wrote:
> Date: Tue, 02 Oct 2007 14:19:20 -0400
> From: Earnie Boyd <[EMAIL PROTECTED]>
>
>
> Quoting Yongwei Wu <[EMAIL PROTECTED]>:
>
> > I can confirm that the PATH_SEPARATOR_CHAR setting in the config.h
On 03/10/2007, Eli Zaretskii <[EMAIL PROTECTED]> wrote:
> > From: Paul Smith <[EMAIL PROTECTED]>
> > Cc: Yongwei Wu <[EMAIL PROTECTED]>, make-w32@gnu.org
> > Date: Tue, 02 Oct 2007 21:39:04 -0400
> >
> > On Tue, 2007-10-02 at 17:26 +0200, Eli Zaretskii wrote:
> > > What advantage is there in using
> Date: Wed, 3 Oct 2007 09:53:43 +0800
> From: "Yongwei Wu" <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], make-w32@gnu.org
>
> > +if exist config.h.W32 GoTo NotCVS
> > +sed -n "s/^AC_INIT(\[GNU make\],\[\([^]]\+\)\].*/s,%%VERSION%%,\1,g/p"
> > configure.in > config.h.W32.sed
> > +echo s,%%PACKAGE%
> From: Paul Smith <[EMAIL PROTECTED]>
> Cc: Yongwei Wu <[EMAIL PROTECTED]>, make-w32@gnu.org
> Date: Tue, 02 Oct 2007 21:39:04 -0400
>
> On Tue, 2007-10-02 at 17:26 +0200, Eli Zaretskii wrote:
> > What advantage is there in using alloca?
>
> So, alloca() is nice because it's dynamic.
But it cou
> Date: Wed, 3 Oct 2007 09:26:46 +0800
> From: "Yongwei Wu" <[EMAIL PROTECTED]>
> Cc: make-w32@gnu.org
>
> Just that I never found the "= '\0'" line here being run :-(, even
> when I have a rule like "test.exe: BUG/". So the copying looks a
> waste of CPU time.
Well, memcpy is very fast, and at
20 matches
Mail list logo
