> Date: Thu, 18 Apr 2013 22:05:33 +0200
> Cc: bug-make@gnu.org, david.s.bo...@gmail.com, psm...@gnu.org,
> bo...@kolpackov.net
> From: Frank Heckenbach
>
> Eli Zaretskii wrote:
>
> > > Date: Thu, 18 Apr 2013 20:39:44 +0200
> > > Cc: psm...@gnu.org, e...@gnu.org, bo...@kolpackov.net
> > > F
Paul Smith wrote:
> On Thu, 2013-04-18 at 20:36 +0200, Frank Heckenbach wrote:
> > And with my progress mechanism, that's exactly what I want. In my
> > case it'd look like this:
> >
> > [Start] Compiling foo.c
> > [Start] Compiling bar.c
> > # time passes
> > foo.c: some error
> > # time passes
Eli Zaretskii wrote:
> > Date: Thu, 18 Apr 2013 20:39:44 +0200
> > Cc: psm...@gnu.org, e...@gnu.org, bo...@kolpackov.net
> > From: Frank Heckenbach
> >
> > Indeed, as you suggested earlier, it might be useful to use the main
> > part of open_tmpfile() (i.e. without the fdopen()), though we'd hav
On Thu, Apr 18, 2013 at 2:39 PM, Frank Heckenbach wrote
>
> This might be right (I was just objecting to your claim that it was
> necessarily so on any 32-bit Unix), and I'd prefer to use fd's
> anyway.
>
Well ... Linux is not Unix, as partisans will proudly tell you, so
technically what I said i
> Date: Thu, 18 Apr 2013 20:39:44 +0200
> Cc: psm...@gnu.org, e...@gnu.org, bo...@kolpackov.net
> From: Frank Heckenbach
>
> Indeed, as you suggested earlier, it might be useful to use the main
> part of open_tmpfile() (i.e. without the fdopen()), though we'd have
> to manually remove the file th
> Date: Thu, 18 Apr 2013 19:09:06 +0200
> From: Frank Heckenbach
>
> > . calculation of combined_output in start_job_command will need to be
> >reimplemented for Windows, since the reliance on st_dev and st_ino
> >makes assumptions that are false on Windows.
>
> What we need is basicall
On Thu, 2013-04-18 at 20:36 +0200, Frank Heckenbach wrote:
> And with my progress mechanism, that's exactly what I want. In my
> case it'd look like this:
>
> [Start] Compiling foo.c
> [Start] Compiling bar.c
> # time passes
> foo.c: some error
> # time passes
> bar.c: some error
> # time passes
>
David Boyce wrote:
> On Thu, Apr 18, 2013 at 10:09 AM, Frank Heckenbach
> wrote:
>
> > FILE is an opaque structure which should never be allocated by user
> > code, so its layout can be implementation specific.
>
> Of course it's an opaque structure. The problem is that the implementation
> can't
Paul Smith wrote:
> On Thu, 2013-04-18 at 19:09 +0200, Frank Heckenbach wrote:
> > This mechanism was unaffected by my output-sync patch, and I
> > expected your change broke it.
>
> I was reading your email with interest, waiting for the punch-line, but
> then after all that description you just
On Thu, Apr 18, 2013 at 10:09 AM, Frank Heckenbach
wrote:
> FILE is an opaque structure which should never be allocated by user
> code, so its layout can be implementation specific.
Of course it's an opaque structure. The problem is that the implementation
can't change its size without breaking
On Thu, 2013-04-18 at 19:09 +0200, Frank Heckenbach wrote:
> This mechanism was unaffected by my output-sync patch, and I
> expected your change broke it.
I was reading your email with interest, waiting for the punch-line, but
then after all that description you just said that the change broke it,
Paul Smith wrote:
> I've applied the patch from Frank.
Thanks. I did some tests and so far everything works in my setup.
Since I was away for a day, I couldn't follow the discussion
earlier, so allow me to respond to several mails at once ...
> I changed the behavior so that the entire recipe
>
12 matches
Mail list logo
