Fixed extra spaces, was due to buffer (had to strip line endings). I'mma make a new thread this mess is my fault.
On Sat, Dec 22, 2018 at 11:03 AM Person Withhats <personwithha...@gmail.com> wrote: > 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 <froda...@gmail.com> wrote: > >> >> >> 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
