Follow up from #678, needed for #1527.
The version of cx_Freeze currently shipped by msys2 is 4.3.3, and it works well enough for our needs. Version 5 breaks all sort of things, and contains some unfixed bugs... but we need it to be able to create a service (#1527), and msys2 is bound to update eventually - we'd better be ready for that.
Issues:
wget https://bitbucket.org/anthony_tuininga/cx_freeze/raw/e1ba6ec6eaad090a76b7095eeb12d15f803a3bde/cxfreeze-postinstall
mkdir /c/msys32/mingw32/DLLs cp /c/msys32/usr/lib/python2.7/lib-dynload/_sqlite3.dll \ /c/msys32/mingw32/DLLs/sqlite3.dll
sys.base_prefix
Scary how many of the tickets on the cx_freeze bug tracker are old and unanswered.
The resulting installation is still completely broken... so maybe we need some of the ignored bugs / pull requests:
cx_freeze can generate an MSI installer, but there is no documentation on how that works: [https://bitbucket.org/anthony_tuininga/cx_freeze/issues/48/ Documentation of how to create desktop or program menu shortcut in Windows]
What a mess.
Looks like the actual bug tracker to use is not sourceforge or bitbucket, but this one now: https://github.com/anthony-tuininga/cx_Freeze/issues.
New issues:
Shame we can't use another project, py2exe doesn't work with our mingw setup.
fix cx_freeze to load libraries from the directory it created
The patch attached (attachment/ticket/1528/cx-freeze-lib.patch) is based on the workaround suggested in No module named __startup__: I can confirm that copying/moving the files from the "lib" directory into same directory as the exe file does work. Extra hacks in r15933 for #1527.
With the cx_freeze 5 workarounds from r15932, we can now generate an installation directory that mostly works. Still TODO:
This is too much work, too much breakage - stub service removed in r15960. Will use a shim for writing the service instead, see ticket:1527#comment:4.
We can re-visit when we really have no other choice, and hopefully the cx_freeze 5.x branch will have matured a bit by then.
MSYS2 has started pushing version 5.. PITA.
So until this is all fixed, we need to pin the package with:
echo "IgnorePkg = mingw-w64-i686-python3-cx_Freeze mingw-w64-i686-python2-cx_Freeze" >> /etc/pacman.conf
For new installations, it is a bit more tricky as downgrades are not possible with pacman, so r16111 switches to using setuptools to install version 4 - just have to hope that this results in a working installation and that the PKGBUILD for version 4 won't need to be revived from version control. (untested - I dare not mess with this stuff since my system works!)
I've copied an archive of the working cx freeze versions here: http://xpra.org/pkg/
And as of r16175, that's the package we install.
Blocker for #1574. Raising.
It might be easier to switch to http://www.pyinstaller.org/. Their documentation is a lot better.
As per comment:1, we can't use pyinstaller as we can no longer use pywin32.
Despite some ugly workarounds in r16970 and using attachment/ticket/1528/cx-freeze-lib.patch, cx_freeze 5.0.2 still fails to package things properly: No module named __startup__ and the workarounds suggested require messing with the pacman build files as building with pip fails on MSYS2...
Even after manually installing the git v5.x version, some problems remain:
Note: the 64-bit builds now use cx_Freeze version 5.x (with manual patching since 5.0.2 is so buggy..)
The python2 / GTK2 builds will remain on the 4.x branch, the 5.x branch works for python3 / GTK3.
r20018 re-enables cx_freeze from the msys2 repositories rather than holding it back at an older version. Packaging works for both python2 and python3 with this version (5.1.1-2)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1528