dumping libzip

[Lubomir I. Ivanov]

On 8 January 2014 10:51, Martin Gysel <me at bearsh.org> wrote:
> Am 08.01.2014 00:22, schrieb Lubomir I. Ivanov:
>> 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!
>
> just to be sure I've understood you two correctly, you agreed to bundle
> zlib's minizip. If that's true, I sink it shouldn't be to hard to let
> qmake decide which one to use, the bundled version statically linked or
> the system one linked dynamically (e.g. if pkg-config file is found).
> this should also make the distros happy which ship zlib's minizip and
> have the 'don't bundle libs if ever possible policy'.
>

i think i wouldn't mind that if it's possible to convince qmake.
but there could be API changes between our bundled minizip and the distro one,
which is definitely an issue and is more work for us. :\

lubomir
--