Update resource-building scripts for future compatibility.

[Deledrius]

This updates the resource.dat creation to render the SVG assets using a newer, maintained Python module "CairoSVG" instead of relying on the Pycairo/rsvg pair which is no longer actively maintained for Python on Windows. Also included are a few Python 3.x+ fixes which should allow the scripts and build system to function with the newer interpreter.

This is a foundation for fixes coming in #650.

[zrax]

Should we also update the appveyor.yml to install/use CairoSVG instead of PyGTK?

[Deledrius]

Yes! I knew I forgot something. I'll add that.

[Hoikas]

Missing requirements.txt with the contents:

cairosvg==1.0.22
pillow

[Deledrius]

We aren't currently using that method. Are you requesting that it be added to this PR?

[Hoikas]

Yes, we want want to expose on master the packages needed for these scripts to work on Py2.7.

[Deledrius]

Alright, will do.

[Hoikas]

This might be nit-picky, but I feel like the requirements.txt should live in the same directory as the resource generation script. The game scripts, for example, don't require the modules listed therein.

[Hoikas]

Too bad the resource.dat is never built on linux-ci since it's part of the plClient build

[Deledrius]

Not currently, but hopefully that will change. I know the scripts run on there because I've done so.

[Deledrius]

Since the requirements file allows specifications based on environment (such as OS), it makes sense to add this to both build systems for consistency (and to watch for accidental breakages).

[Deledrius]

I feel like the requirements.txt should live in the same directory as the resource generation script.

I considered this, but then the question is when is this step executed?

I think this is redundant. We currently install all dependencies in the apt-get/vcpkg steps, and let CMake work out what's enabled and available. This is consistent with that approach. If these Python modules are unavailable, or not requested in the build, CMake will respond appropriately.

Also, a dependency-installation step that requires a file nested deep inside the project tree seems prone to breakage. Unless we want to have CMake handle running PIP as a custom command inside the step that sets CAN_BUILD_RESOURCE_DAT on, I don't see a better way to do this (and installing dependencies during configuration seems like an equally bad idea).

I see this file as a project-wide dependencies install list, which just happens to only be used by a single sub-project currently. That would appear to be the general intent of it. We can also nest them... perhaps you'd prefer that? If this requirements file referenced nested ones for any projects that need it, then the CI steps still only need reference the base file.

Review addressed.

[Hoikas]

LGTM