Wireshark-dev: Re: [Wireshark-dev] Status Cmake Win32 support

From: Joerg Mayer <jmayer@xxxxxxxxx>
Date: Mon, 2 Dec 2013 11:54:35 +0100
On Sun, Dec 01, 2013 at 10:35:50PM +0000, Graham Bloice wrote:
> On 30 November 2013 23:18, Joerg Mayer <jmayer@xxxxxxxxx> wrote:
> > I have no idea why/how this is supposed to work: Is Qt5 supposed to
> > automagically
> > add the right msvc version back into the path?
> > After applying and testing this it didn't fail right away but it no longer
> > found Qt5LinguistTools and Qt5PrintSupport.
> >
> 
> My qt is in C:\Qt\Qt-5.1.1-MSVC2010-win32-ws, and QT_BASE_DIR is set to
> this.  I used the Qt-5.1.1-MSVC2010-win32-ws.zip from the Wireshark web
> site.  I might have used the nmake target "install_qt" to do this, I can't
> remember.

Should now be fixed - your patch was correct, I misread an earlier patch to
config.nmake.

> >    4. As I've moved over to building the GTK3 version, some CMake FindXXX
> > >    modules had to be fixed, not entirely convinced by my changes here,
> > but it
> > >    works for me (Findxxx.patch).
> >
> > I do my builds with GTK3 as well and they seem to build just fine. I agree
> > that
> > using gtk[23] is a hack and you cleaned that up properly. What I don't
> > understand
> > is why you removed the "IF( NOT GMODULE2_FOUND  )" (or similar) in
> > FindGMODULE2.cmake and FindGTHREAD2.cmake.
> >
> 
> I've reverted the GMODULE2 and GTHREAD2 changes and GTK3 still builds for
> me.  I haven't checked GTK2 builds, is there much point on Windows?

I will check them, to be complete.

> I still have the issue with GTK3, in that I have to comment out the path
> "corrections" in FindGTK3.cmake.

Hmm, can you please explain the problems you are encountering - I'd like to
fix them. In case it involves rewriting the results from pkg-config, can you
please include the .pc file?

> My current hit-list of things to do (some you've touched in in your
> message):
> 
> 1.  Copy build artifacts (and 3rd party dlls etc.) to a directory for
> running (as per nmake).  Almost like install.  Note that the exact location
> of the build artifacts depends on the type of build actually made (debug,
> release etc.)

I'll look into that.

> 2.  Fix the generation of the manifext files (in progress GMB), and include
> in build (use SED to produce .manifest from .manifest.in), should go into
> correct intermediate build dir (e.g. wireshark.dir\Release).  Note needs to
> know processor architecture, so maybe should be a prebuild custom command
> for each target).

I have no idea what this is about but native nmake seems to do something here
as well. msbuild seems to generate something here.

> 3.  Fix the generation of the .rc files (in progress GMB), and include in
> build (use SED to produce .rc from .rc.in), should go into correct
> intermediate build dir (e.g. wireshark.dir\Release).  Note associated .ico
> and .manifest.

dito.

> 4.  Fix the use of zlib, so that zlib is built by CMake and doesn't require
> nmake build first.

This should be done in the setup process.

One of the remaining points is to make the setup process independent of
nmake but we need a concept here first that should probably then be applied
to the native nmake too.

> 5.  Fix PortAudio.

dito.

> 6.  Fix CMake to find a working pkg-config.exe (only found in gtk2\bin at
> the moment, missing from gtk3), currently manualy copied to build dir
> (along with intl.dll and libglib-2.0-0.dll)

I use pkg-config from cygwin, so it might be easiest to update the installation
manual.

> 7.  Fix qtshark use its own .rc file (not done in nmake either)

> 8.  Fix build of plugins.

They build on my system (cmake with nmake and msbuild).

> 9.  Fix build of executables that use WTAP_PLUGIN_SOURCES.

Have to check what you are talking about :-)

Ciao
    Jörg

-- 
Joerg Mayer                                           <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.