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
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,
On Thu, Apr 18, 2013 at 10:09 AM, Frank Heckenbach
f.heckenb...@fh-soft.dewrote:
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
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 said
David Boyce wrote:
On Thu, Apr 18, 2013 at 10:09 AM, Frank Heckenbach
f.heckenb...@fh-soft.dewrote:
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
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
[End]
Date: Thu, 18 Apr 2013 19:09:06 +0200
From: Frank Heckenbach f.heckenb...@fh-soft.de
. 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
Date: Thu, 18 Apr 2013 20:39:44 +0200
Cc: psm...@gnu.org, e...@gnu.org, bo...@kolpackov.net
From: Frank Heckenbach f.heckenb...@fh-soft.de
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
On Thu, Apr 18, 2013 at 2:39 PM, Frank Heckenbach f.heckenb...@fh-soft.dewrote
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
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 f.heckenb...@fh-soft.de
Indeed, as you suggested earlier, it might be useful to use the main
part of open_tmpfile() (i.e. without the fdopen()),
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
bar.c: some
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 f.heckenb...@fh-soft.de
Eli Zaretskii wrote:
Date: Thu, 18 Apr 2013 20:39:44 +0200
Cc: psm...@gnu.org, e...@gnu.org,
12 matches
Mail list logo
