tidy up the win32 build

[Antoine Martin]

Related to #678 and #640.

• building on 64-bit windows system is painful, r9920 fixes most of that
• we have too many inconsistent paths dumping in to C:\

[Antoine Martin]

As of r9921, we can now move all the build libs into a prefix, it still defaults to C:\ for backwards compatibility, but I've moved my test build system to use E:\Xpra-Build-Libs which now looks like this:

ffmpeg2-win32-bin
libwebp-windows-x86
Microsoft.VC90.CRT
Microsoft.VC90.MFC
vpx-1.4
x264

This could also be used to lock a specific version to a specific set of libraries.

Note: we now support both 32-bit and 64-bit helpers (ghoscript for printing, etc) - we still prefer the 32-bit version if present so that we can build 32-bit installers on a 64-bit system which may have both versions of the tools. This has negligible cost: printing is not performance critical, but may have security implications as 64-bit tends to be safer. (this could be changed later)

[Antoine Martin]

For the record, this is how I built stuff with msvc 2008:

• jpeg9a as per ​OSError: decoder jpeg not available on Windows, but with these steps for building with 2008 instead of 2010:

  nmake -f makefile.vc setup-vc6
  nmake -f makefile.vc
  

Then copy the headers and lib files to the python installation directories.

• zlib as per ticket:90#comment:38
• webp:
  • build as per its README, but changing to a dynamic build: nmake /f Makefile.vc CFG=release-dynamic RTLIBCFG=dynamic OBJDIR=output
  • copy the include and lib files as per ticket:90#comment:38
• then pillow should build with all the codecs we care about (jpeg, png and webp), see ​OSError: decoder jpeg not available on Windows

Not done yet:

• pycrypto with gmp or mpir: see ticket:373#comment:7, ​Building GMP library with Visual Studio? and ​How to Install and Run GMP on Windows Using MPIR
• ffmpeg: no go so far, but it should be do-able - see ​4.2 Microsoft Visual C++ or Intel C++ Compiler for Windows
• nvenc server support, looking at the example code - we may not need directx

[Antoine Martin]

r10052 backported this to v0.14.x and v0.15.x, and we can now have a different lib directory for each branch.
ie: v0.15.x will try to find:

• E:\Xpra-Build-Libs-v0.15.x\
• E:\Xpra-Build-Libs\
• C:\

So everything should work as before for all branches, and you can either use a common directory for all, or individual directories as needed.

@smo: please close to ACK, assuming nothing is broken...

[Smo]

Tested this works as expected. I will probably leave mine at the default location for now but I like how this works now.

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/916