exaile / exaile-sdk-win Goto Github PK

AppVeyor limits the inter-build cache to 1 GiB compressed (zip?), which we've exceeded.

I suspect that this is mostly because of old package files, which we can delete with pacman -Sc.

In addition, there are a few new packages that get pulled in. Comparing the current build log and the previous one, they are:

binutils boost ceres-solver cppunit crt-git eigen3 freeimage gcc gflags glog glsl-optimizer-git hdf5 headers-git hlsl2glsl-git icu isl jxrlib leptonica libunwind metis ogre3d suitesparse szip tesseract-ocr tinyxml uasm windows-default-manifest winpthreads-git zziplib

(The biggest one is ogre3d at 112 MiB compressed.)

As far as I can tell, most of these are ultimately pulled due to opencv (dependency of gst-plugins-bad), so if we can completely blacklist opencv from pacman that would probably solve everything.

We need the SDK tarball to be small enough not to run into AppVeyor and GitHub's storage limits, but it's generally not a big deal because deleting old builds will probably work.

Here are statistics from the latest SDK and Exaile builds:

• SDK size: 296 MB
• Compression time: 5 m 32.100 s
• Upload time: not measured, but around 10 s based on observation.
• Download time: 5.683 s
• Decompression time: 1 m 52.770 s

The most important here is decompression time, because it's done on every Exaile build. It's also decent part of Exaile's build time (total build time is 6 m 27 s).

We should try other compression algorithms to see if we can improve this. If we have to increase the SDK size by 50 MB I'd say that's still acceptable. And if we can reduce compression time without hurting decompression time that would be great as well.

The main candidate I'm thinking about is zstd, which ArchLinux has moved to for their packages. It has fast compression and decompression times and the file size is at least decent.