Minizip integration in Subsurface

[Alberto Corona]

On Tue, Mar 11, 2014 at 01:03:41PM +0200, Lubomir I. Ivanov wrote:
> forwarded to the mailing list.
> (discussions of this type should be public)
> 
> On 11 March 2014 03:33, Alberto Corona <albcoron at gmail.com> wrote:
> > Hi my name is Alberto, I'm planning on writing my GSoC proposal for minizip
> > integration. I've taken a look at the source and it seems that most of the
> > zip handling is done through file.c/.h with the paths being handled in the
> > platform specific .c files (linux.c, macos.c..), is this correct?
> 
> hi Alberto,
> 
> your assumption about the platform files is correct, while windows.c
> is the main reason for the abstraction.
> file.c is used to read files, and parsing them by determining roughly
> their type.
> ZIP files are handled in this particular source file, but also in
> other places where libzip is used directly.
> 
> i saw your GSoC application and you have one of the good ones thus far
> (speaking outside of the context of just answering the Q/A), but it
> would be best if you submit *at least* another meaningful patch apart
> from the changes you did in 0d62efaa393, which were mostly cosmetic.
> if you wish you can move away from the "no-marble" idea and do
> something else; preferably something in the .c files.
> 
> just browse the code base and look for things that can be improved...
> 
> lubomir
> --

So I was digging around in the mailing list archives and found this
discussion on the move to minizp:
http://lists.hohndel.org/pipermail/subsurface/2014-January/009644.html

Was a decision reached on how minizip will be used (static v shared)?
I've managed to install development versions of minizip on Arch and
Fedora though Debian/Ubuntu seem not to have it at the moment. Minizip
is also available for cross compiling on Fedora and for Mac through
homebrew.