[meld/meld-3-18: 1/4] Provide dummy stdout to make multiprocessing work with cx_freeze GUI (#196)

[Kai Willadsen <kaiw src gnome org>]

commit 810ef9e8dbadea9278a6acf3f4c616ed2722c917
Author: Vasily Galkin <galkin-vv ya ru>
Date:   Wed May 30 21:50:24 2018 +0300

    Provide dummy stdout to make multiprocessing work with cx_freeze GUI (#196)
    
    Stdout is replaced not only with pythonw but also if it is None.
    Broken stdout workarounding is moved before multiprocessing.freeze_support
    because in python 3.4 multiprocessing.freeze_support() calls stdout.flush()
    before process exit and it fails if stdout is None

 bin/meld | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
---
diff --git a/bin/meld b/bin/meld
index 24ca2762..e3a12380 100755
--- a/bin/meld
+++ b/bin/meld
@@ -24,19 +24,20 @@ import subprocess
 import sys
 from multiprocessing import freeze_support
 
-# Main module hasn't multiprocessing workers, so not imported in subprocesses.
-# This allows skipping '__name__ == "main"' guard, but freezed case is special.
-freeze_support()
-
 # On Windows, pythonw.exe (which doesn't display a console window) supplies
 # dummy stdout and stderr streams that silently throw away any output. However,
 # these streams seem to have issues with flush() so we just redirect stdout and
 # stderr to actual dummy files (the equivalent of /dev/null).
 # Regarding pythonw.exe stdout, see also http://bugs.python.org/issue706263
-if sys.executable.endswith("pythonw.exe"):
+# Also cx_Freeze built with Win32GUI base sets sys.stdout to None
+# leading to exceptions in print() and freeze_support() that uses flush()
+if sys.executable.endswith("pythonw.exe") or sys.stdout is None:
     devnull = open(os.devnull, "w")
     sys.stdout = sys.stderr = devnull
 
+# Main module hasn't multiprocessing workers, so not imported in subprocesses.
+# This allows skipping '__name__ == "main"' guard, but freezed case is special.
+freeze_support()
 
 def disable_stdout_buffering():