Wireshark mailing list archives
Re: Windows build setup - Concept required
From: Graham Bloice <graham.bloice () trihedral com>
Date: Thu, 5 Dec 2013 22:20:58 +0000
On 5 December 2013 19:59, Gerald Combs <gerald () wireshark org> wrote:
On 12/4/13 12:27 PM, Joerg Mayer wrote:Hello, as Graham and I are working on getting the Windows build process to a) work at all and b) be on par with the current nmake build process we currently rely on the setup infrastructure of the nmake build. I really don't like porting the "nmake -f Makefile.nmake setup" to cmake. Not because it is hard to do but because the current setup has various shortcomings1) zlib is installed as source only 2) portaudio is installed as source onlyI know there are historical reasons for this but are they still valid? Zlib packages are available from the OpenSUSE Build Service (linked against msvcrt.dll) and Nuget (linked against multiple runtimes). Portaudio is also available from OBS.
I could try them out.
3) Every package is installed into its own subdirectory, sometimes with its own structureCoApp has a standardized directory layout for libraries and include files called "Pivots": http://coapp.org/reference/autopackage-ref.html#Pivots "Pivot" is a nicer name than "deep explodey directory tree" but it seems sensible and worth adopting IMHO.
I still haven't looked into CoApp. How does it play with Chocolatey?
4) glib2 contains zlib headers that break windows builds 5) glib3 contains zlib headers that break windows buildsThis should be reported as a bug at https://build.opensuse.org/package/show/windows:mingw:win64/mingw64-zlib I'm sure patches are welcome.
I shall try to do this.
6) krb5 contains includes that export krb5-build internal flags and thus cause warnings during compilesIs there a better library we can use for Kerberos? MIT, Secure Endpoints, and Heimdal all seem to provide packages that almost-but-not-quite meet our needs. I tried cross-compiling MIT Kerberos and Heimdal using MingW in the past but didn't have much luck.6) Except for gtk3 no packages provide compile (includes, cflags) or linking (libs, ldflags) information. 7) glib3 contains pkg-config files, but they contain a wrong paths and unuseable compiler (gcc) flagsThe existence of the .pc files depends on my packaging scripts and the OBS .spec files for OBS-sourced packages. Adding them shouldn't be too difficult. The tricky part is getting them to point to the correct location on Windows. I'm not sure if we can use or modify the stock .pc files or if we'd have to create our own.
My experiments with pkg-config from the gtk2 bundle and from pkg-configlite and the gtk3 bundle .pc files shows that "it just works". The bundle .pc files have odd *nixy type paths in them but pkg-config and CMake sort all that out (with my modified FindGTK3.cmake)
8) The current setup process does not install QTI've been hesitant to switch this on since it's such a large download and I'm not sure which "Qt" should be installed. The Qt project provides official 32- and 64-bit installers for VS 2012 and a 32-bit installer for VS 2010. We provide 32- and 64-bit packages for VS 2010. We sign the EXEs and DLLs in our packages but the Qt project doesn't. I don't know if anyone provides VS 2013 packages.
Folks only have to download it as often as it changes! Or is the issue server resources?
9) To build qtshark without wireshark still requires the installation of gtk2 or gtk3 for glib, gmodule, gthreadI think we should switch from the separate wireshark-gtk2 and wireshark-qt-release directories to a common deployment directory, e.g. "wireshark-deploy" or "wireshark-stage". This would presumably help to unify our build targets.
Ack
(I'd also like to get rid of ui/qt/QtShark.pro at some point in favor of CMake. Qt Creator supports CMake projects well enough, and having to maintain QtShark.pro for different platforms is a pain.)10) The setup process does not allow for the simultanous installation of gtk2 and gtk3Does GTK3 work well enough on Windows to drop GTK2? This would simplify things quite a bit.
It's OK for me but there are some folks complaining about it from the cheap seats :-)
11) The installation of some build tools (python, cmake, cygwin-stufflikecat, bash) might be automated - depending on the setup scriptlanguagemaybe not all of them. So maybe something more similar to the macosx setup is wanted. Not maybe the compile-it-yourself approach but an installation into a standard directory structure. So what I'd like to have is a script (.bat or maybe Powershell) thatworkssimilar to the macosx-setup.sh script: - Contain a list of packages and their versions - Download missing packages - Download missing tools - Install not-yet-installed packages (includes, libs) into a standard directory structure Feedback, ideas, details anyone?Sounds good to me. I like Graham's suggestion of using Chocolatey/Nuget since they're currently the best option for package management under Windows. I'd be willing to convert our current Windows libraries to Nuget packages, and have them conform to Coapp's directory layout[1]. If we could find or create Chocolatey packages for Bison and Flex that would go a long way toward dropping the requirement for Cygwin.
The GNUWin32 project provides Bison and Flex and sometime in the past in my "Removing the Cygwin dependency" experiments I did get the GNUWin32 binaries to do the job. I'll have a hunt for that VM, hopefully I still have it somewhere. I
[1] The end goal being that someone else take over maintenance of the packages. Some men dream of the heavens. I dream of no longer having to create third-party Windows development libraries.
That would be nice, but if we are signing packages it might continue for some time yet.
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Windows build setup - Concept required Joerg Mayer (Dec 04)
- Re: Windows build setup - Concept required Gerald Combs (Dec 05)
- Re: Windows build setup - Concept required Pascal Quantin (Dec 05)
- Re: Windows build setup - Concept required mmann78 (Dec 05)
- Re: Windows build setup - Concept required Christopher Maynard (Dec 05)
- Re: Windows build setup - Concept required Pascal Quantin (Dec 05)
- Re: Windows build setup - Concept required Graham Bloice (Dec 05)
- Re: Windows build setup - Concept required Pascal Quantin (Dec 05)
- Re: Windows build setup - Concept required Gerald Combs (Dec 05)
- Re: Windows build setup - Concept required Joerg Mayer (Dec 05)
- Re: Windows build setup - Concept required Bill Meier (Dec 05)