[CMake] Handling real-time output from execute_process

[Person Withhats]

Oops, forgot to add mailing list.

Also, here's some sample CMake output that shows some issues.
1) Carrige return doesn't replace previous line of output == tons of %'s
2) Perhaps cuz I'm forcing no buffer in CMake it causes the below extra 2
new lines on each line of output?? Should be condensed at least...

What I'm using to unbuffer:
class Unbuffered(object):
   def __init__(self, stream):
       self.stream = stream
   def write(self, data):
       self.stream.write(data)
       self.stream.flush()
   def writelines(self, datas):
       self.stream.writelines(datas)
       self.stream.flush()
   def __getattr__(self, attr):
       return getattr(self.stream, attr)

sys.stdout = Unbuffered(sys.stdout)
sys.stdout.buffer = Unbuffered(sys.stdout.buffer)



Downloading/Extracting SDKs...



Download URL: "XXXXXX"



Downloading 779738578 Bytes



65536 [0.01%]



131072 [0.02%]



196608 [0.03%]



262144 [0.03%]




On Fri, Dec 21, 2018 at 11:56 PM frodak17 <frodak17 at gmail.com> wrote:

>
>
> 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/ce5aaa03/attachment.html>