<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 21, 2018 at 11:16 PM Person Withhats <<a href="mailto:personwithhats2@gmail.com" target="_blank">personwithhats2@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>1) I want output in real time on a Windows system(no tail), and piping output to a file then reading it is a very poor solution. 'just check the contents in note pad'....<br></div>2) This is a general-purpose solution and not something I'm making just for myself, hacky fixes are not an option.<br></div><br></blockquote><div><br></div><div>By default the command runs in the same console as cmake.</div><div>So if it is a typical executable that prints to standard output it will be shown with the rest of the cmake output.</div><div>Also the executable output can be captured to a file or variable instead of being shown.<br></div><div>What you can't do is capture it in a variable or file and display it at the same time.<br></div><div><br></div><div></div><div>When you use '"cmd" /c "start /wait
download_sdks.exe"' this spawns a new console window that cmake knows nothing about.</div><div>This breaks the normal usage of
execute_process() because "start /wait" creates an independent console to run download_sdks.exe.</div><div></div><div>cmake has no influence over this second console. So while you can see its outputs you can't capture it in any way through cmake.</div><div></div><div><br></div><div>You get a return value of 0 in this case because the errorlevel from the second console isn't passed back correctly to the first console and then back to cmake.</div><div>A quick google search shows that this would work: COMMAND "cmd" /c "start /wait
download_sdks.exe
& exit ^!errorlevel^!" assuming that
download_sdks.exe actually returns any error codes.</div><div><br></div><div>
<div>You don't say why download_sdks.exe can't be run as a normal executable.</div><div>Nor do you say why you aren't using "start /wait /b" to keep everything in the same console as cmake is running in.</div><div>You said you want to see the output from the command but are clearly trying to capture the output in a variable instead but don't mention why.<br></div><div></div>
</div><div><br></div><div>
I guess it's hacky but the tool download_sdks.exe seems to be broken in terms of console output (as it has to be run in a cmd.exe shell and not just as a standalone executable) and you have to compensate for that.
</div><div>That leaves you with redirecting the output to a file. This saves it so your script can read this file contents and do whatever you originally intended by capturing OUT and you can monitor as the file gets updated.<br></div><div><br></div><div>Of course Windows has options for monitoring a file, powershell comes with "Get-Content mylogfile.log -Wait". I would have thought most developers have Git for Windows installed and it does provide tail.</div><div><br></div><div>Now if download_sdks.exe can be fixed to print to standard out without all these cmd.exe console redirections than you can simply spawn powershell, run
download_sdks.exe
, use a Tee-Object to log the data to a file and still see its output in the original cmake console. CMake can then read the log back in and do whatever processing you originally intended.</div><div><br></div><div>Now the GUI does seem to lag behind console output when hitting the configure button (at least when I tested it because I never used it before). In this case you may want to spawn a separate console to see the output instead of waiting for the GUI to display it. I'm not sure it's reasonable to expect the GUI stop button to kill a process it doesn't know about. You just close the console window and the GUI recognizes that execute_process() was interrupted. Not sure why you wouldn't consider that as acceptable. So you would still need to capture output to a file to process it.<br></div></div></div></div>