On Fri, Dec 21, 2018 at 11:16 PM Person Withhats <personwithha...@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.
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake