[CMake] Handling real-time output from execute_process

[frodak17]

On Fri, Dec 21, 2018 at 11:16 PM Person Withhats <personwithhats2 at gmail.com>
wrote:

> 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'....
> 2) This is a general-purpose solution and not something I'm making just
> for myself, hacky fixes are not an option.
>
>
By default the command runs in the same console as cmake.
So if it is a typical executable that prints to standard output it will be
shown with the rest of the cmake output.
Also the executable output can be captured to a file or variable instead of
being shown.
What you can't do is capture it in a variable or file and display it at the
same time.

When you use '"cmd" /c "start /wait download_sdks.exe"' this spawns a new
console window that cmake knows nothing about.
This breaks the normal usage of execute_process() because "start /wait"
creates an independent console to run download_sdks.exe.
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.

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.
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.

You don't say why download_sdks.exe can't be run as a normal executable.
Nor do you say why you aren't using "start /wait /b" to keep everything in
the same console as cmake is running in.
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.

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.
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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20181222/8a49d663/attachment-0001.html>