Hey guys.
(For the impatient, scroll to the end of the mail.)
Some of you might that on Windows, running some commands opens an extra console window and so capturing the program's output is not possible. That happens e.g. when compiling, linking, or running make commands in Geany on Windows. There is a long story behind, IMO that should be fixed in GLib's spawn commands but recently I read Tor, the responsibly dev, said this is not GLib's job but instead in the app's reponsibility. This is all ok but I and probably Nick too, won't write any code using the Windows API and CreateProcess() just to get it working.
Some time ago, I added some code to the Windows port that creates an additional console window on startup of Geany, this can be activated by the "-v" command line option. This has the advantage, when running a compiler or make or whatever, no extra console window will open and we can capture the program's output. But of course, it isn't nice to have always this extra console window open. And more importantly, with this window, the Run commands sometimes[1] don't work at all or cause weird behaviour[2]. This extra console window was also never intended for daily use, just as a little help when testing code on Windows.
There are two ways to go: a) fix all these problems by writing a lot new code around Windows' CreateProcess() API and make it all working b) run Builds commands on Windows synchronously for what we have already that CreateProcess() code in Geany (done by Pierre Joye, many many thanks)
Solution A would be of course the best one and desirable but it needs someone to write the code and with the necessary knowledge and time to do this. So, I'd vote for solution B, attached is a quick hack on the src/build.c with the necessary changes. Tested and seems to work. Instead of running the Build commands asynchronously, they are run directly. This also has disadvantages: a) the whole Geany window freezes while the Build command is running b) the output is "sorted", that is, first the program's stdout is put into the Compiler window, then the program's stderr
But therefore we have the advantage that the build system on Windows gets more usable.
### ### END ### ### So, to not be even more boring with details, the final question is:
Are there any objections in using the attached patch and making the Build commands on Windows running synchronously?
[1] for some commands, only noticed while testing code, not sure why [2] In #2723005, the user reported 100% CPU usage when using the Run command. There was also a related issue with running Java apps on Windows, IIRC.
Regards, Enrico