[Scummvm-devel] Daily/nightly Win32 builds

[Max Horn]

Am 15.06.2011 um 22:34 schrieb Michael Madsen:

>> -----Original Message-----
>> From: Max Horn [mailto:max at quendi.de]
>> Sent: Wednesday, June 15, 2011 10:17 PM
>> Cc: scummvm-devel at lists.sourceforge.net
>> Subject: Re: [Scummvm-devel] Daily/nightly Win32 builds
>> 
>> PS: I was quite surprised when I learned that scummvm.exe is 192 MB,
>> unstripped. The Mac OS X executable, for comparison, is just 30M. Granted,
>> that's without static linking stuff, but that just adds a few MB. Anybody
>> got a clue why the unstripped win32 exe is *that* large? Is it really only
>> the debug symbols?
> 
> I just pulled the latest changes and ran a standard configure/make on my computer, using GCC 4.3.3. The resulting binary came out at ~67MB (70,308,408 bytes), and compressing it with 7-zip resulted in a 12.6MB archive (13,254,283 bytes).
> 
> After running strip on the binary, the new size was 15.82MB (16,586,752 bytes), 3.35MB (3.520.691 bytes) compressed.

Was that with all engines enabled? Could you also give us the figures for using .tar.bz2 ? Though we really should provide the win32 builds as .zip, shouldn't we? For maximal compatibility... or do we think we can trust testers to install fancy stuff like a 7zip decompressor? In that case, we could also provide binaries compressed with p7zip. I just installed version 4.58 which is shipped with Debian 5 (and I also installed the Debian nsis package). This version is dated, but should be enough for basic needs, I'd hope... 



> 
> Not sure where the 192MB figure is from - maybe that's with all engines enabled - but it certainly seems to account for a lot, and it seems like it would indeed be very reasonable to provide stripped binaries as a low-bandwidth alternative.

The 192 MB comes from downloading the latest mingw32 build from buildbot, unpacking it, and looking at scummvm.exe in there ;). And yeah, on buildbot we use --enable-all-engines for development builds.




Cheers,
Max