dumping libzip

Lubomir I. Ivanov neolit123 at gmail.com
Tue Jan 7 15:22:22 UTC 2014


On 8 January 2014 01:12, Dirk Hohndel <dirk at hohndel.org> wrote:
> On Wed, 2014-01-08 at 01:07 +0200, Lubomir I. Ivanov wrote:
>> >> i think we can.
>> >> there is just some basic source code in the lines of "io functions
>> >> like fopen", "zipping stuff", "unzipping stuff" and some helper
>> >> headers.
>> >> we need to include those .o files in our files and simply use the zlib
>> >> shared library.
>> >
>> > Why a shared library? Why not just link them into our executable?
>> >
>> >> the i/o buffer support from minizip is not part of zlib upstream and
>> >> it seems to be only in the minizip upstream.
>> >> we technically need that in locations like subsurfacewebservices.cpp
>> >> and file.c, but we can still manage to open files instead of buffers.
>> >
>> > I assumed based on your last set of emails we were planning to use the
>> > minizip upstream as starting point.
>> >
>>
>> we can, but i was concerned about our code base inflation based on
>> previous emails in this thread.
>> the minizip upstead adds some extra 1k-2k lines of code just for that
>> buffer i/o API.
>>
>> if we use zlib upsteam minizip does not have support for buffer i/o.
>
> Is it worth the 1-2k? For us it's just a quick detour via a temp file. I
> think that's overkill to avoid the temp file.
>

it think we can skip the buffer support for now.
i generally i don't understand libraries not supporting file i/o next
to buffer i/o.
it's pretty much the same thing.

when we started adding gettext support for the GTK build i wrote this
in my spare time for fun:
https://github.com/neolit123/cfg2

one of the first features i've added was buffer readout...pretty much. :)

>
> Please send patches. This sounds like the right thing to do.
>

will try to do so!

lubomir
--


More information about the subsurface mailing list