ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Custom zlib for Windows builds

From: Pascal Quantin <pascal.quantin@xxxxxxxxx>
Date: Mon, 27 Apr 2015 23:19:47 +0200
2015-04-27 23:13 GMT+02:00 Gerald Combs <gerald@xxxxxxxxxxxxx>:
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.

Indeed this is something I did myself in the past for gtk2 or gnutls packages (you probably pointed me to this script at some point, but I do not remember the details). Fortunately download-mingw-rpm.py has a rather good dependency tracking (better than my initial trial attempts based on Dependency Walker, it as painful...).
 

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.

This last objective seems to be a good plan ;)