dumping libzip

[Lubomir I. Ivanov]

On 8 January 2014 00:49, Dirk Hohndel <dirk at hohndel.org> wrote:
> On Wed, 2014-01-08 at 00:44 +0200, Lubomir I. Ivanov wrote:
>> > It's a bit early still for us here in Australia... but my reaction is
>> > this:
>> >
>> > a) I don't want to add a dependency to a library that is hard to get for
>> > people.
>> >
>>
>> i guess, that's the whole point of including a library snapshot in our source.
>> it will improve over libzip, which does not have support for reading
>> buffers and is broken on win32 paths.
>
> Understood - that's why we are talking :-)
>
>> > b) If we add minzip to our sources (which based on the license we can)
>> > we de-couple ourselves from its upstream. But that may be acceptable.
>> >
>>
>> i think it can fit much better.
>> i see a lot of c++ projects that do that and wrap the minizip around
>> c++ code and handle zip archives locally not depending on libraries
>> like libzip.
>> libzip has requests for buffer i/o made early 2012, and the response
>> is "Unfortunately, no", which i don't think is serious for such
>> project.
>>
>> > c) I don't want to carry around code that isn't used - so what's the
>> > delta of functionality that it offers versus the functionality that we
>> > actually need? Or said differently, are there parts that we could easily
>> > remove while maintaining the functionality that we need? In order to
>> > make the library smaller and easier to maintain?
>> >
>>
>> 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?
>

sorry missed this one,

we are going to statically link minizip, but zlib will be still sharer
on all OS (TMK).

lubomir
--