<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 15, 2013 at 7:41 PM, Robert Kern <span dir="ltr"><<a href="mailto:robert.kern@gmail.com" target="_blank">robert.kern@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="font-family:arial;font-size:small">On Fri, Nov 15, 2013 at 7:28 PM, David Cournapeau <<a href="mailto:cournape@gmail.com" target="_blank">cournape@gmail.com</a>> wrote:</span><br>

><br>> On Fri, Nov 15, 2013 at 6:21 PM, Charles R Harris <<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>> wrote:<br>

<br></div><div>>> Sure, give it a shot. Looks like subprocess.Popen was intended to replace os.system in any case.<br>><br>> Except that output is not 'real time' with straight Popen, and doing so reliably on every platform (cough - windows - cough) is not completely trivial. You also have to handle buffered output, etc... That code is very fragile, so this would be quite a lot of testing to change, and I am not sure it worths it.<br>



<br></div>It doesn't have to be "real time". Just use .communicate() and print out the stdout and stderr to their appropriate streams after the subprocess finishes.<br></div></blockquote><div><br></div><div>

Indeed, it does not have to be, but that's useful for debugging compilation issues (not so much for numpy itself, but for some packages which have files that takes a very long time to build, like scipy.sparsetools or bottleneck).</div>

<div><br></div><div>That's a minor point compared to the potential issues when building on windows, though.</div><div><br></div><div>David</div></div></div></div>