Wireshark-dev: Re: [Wireshark-dev] Custom zlib for Windows builds
From: Gerald Combs <gerald@xxxxxxxxxxxxx>
Date: Mon, 27 Apr 2015 14:13:47 -0700
On 4/27/15 1:21 PM, Pascal Quantin wrote:
> 
> 2015-04-27 20:43 GMT+02:00 Gerald Combs <gerald@xxxxxxxxxxxxx
> <mailto:gerald@xxxxxxxxxxxxx>>:
> 
>     On 4/27/15 8:57 AM, Pascal Quantin wrote:
>     >
>     >
>     > 2015-04-27 17:55 GMT+02:00 Graham Bloice <graham.bloice@xxxxxxxxxxxxx <mailto:graham.bloice@xxxxxxxxxxxxx>
>     > <mailto:graham.bloice@xxxxxxxxxxxxx
>     <mailto:graham.bloice@xxxxxxxxxxxxx>>>:
> 
>     >     I'll have a go at producing a new one, what name do we give it
>     >     zlib-1.2.8-ws?
>     >
>     >
>     > That's our usual naming scheme yes.
> 
>     Would a "wireshark-windows-thirdparty" repository be useful for managing
>     this? I've been thinking about adding something for the scripts I use to
>     create the OpenSUSE-derived packages.
> 
> 
> What would we use it for? Storing the scripts / patches used to generate
> the packages? If yes, I guess storing those in the zip file (as you started
> to do for some packages) makes it easier to find the relevant info
> (typically I should have added the steps - including the compilation flags
> - used to generate libgcrypt, instead of saying that it was compiled
> without AES-NI support).
> Or we could eventually create a folder per package in this new repository,
> and then put the relevant stuff (and replace it each time we upgrade the
> package). But I fear it would make it harder to find the info afterwards.
> Or maybe you had something else in mind?

Initially it would be used to store the scripts I use to generate the
packages in the wireshark-winXX-libs SVN repository. The OBS packages are
built in two stages: First, a "nolib" zip file is created on Linux using
download-mingw-rpm.py, then the import libraries are built on Windows using
the Visual Studio library manager and zipped up. The second (lib + zip)
script is part of the final archive but not the first.

Ultimately I'd like to have a set of scripts that create NuGet packages
similar to what CoApp (which appears to be abandoned) was doing, preferably
without requiring multiple platforms. At the very least I'd like to remove
myself as a dependency.