Re: Status Cmake Win32 support

[Joerg Mayer <jmayer () loplof de>]

On Sat, Oct 12, 2013 at 07:31:27PM +0100, Graham Bloice wrote:
> On 11 October 2013 16:09, Joerg Mayer <jmayer () loplof de> wrote:
>
>
> > Another milestone hit:
> >
> > - Win 32bit: The following executables build and run from the build
> > directory
> >   (as well as capture if they should be able to). *: Acutally tested
> >   $ ls *exe
> >   capinfos.exe* dumpcap.exe  mergecap.exe  randpkt.exe   reordercap.exe
> >  tshark.exe*
> >   dftest.exe    editcap.exe  qtshark.exe*  rawshark.exe  text2pcap.exe
> > wireshark.exe*
>
> Using CMake to generate a MSVC2010 solution, I can't get near that number
> of successful executables.  I have used the CMake generated solution with
> command line build (msbuild Wireshark.sln) and from within VS.

I can look into this but probably not within the next two weeks as I'm currently
trying to get this to "featurecompleteness" first and because I don't know that
process (msbuild) at all. OK, I don't expect to reach that within two weeks, but
I hope to have the most important items covered by then.

>  I do have
> modified CMake files in an attempt to group the "projects" in Visual Studio
> into some sort of logical tree rather than the large flat list.  I don't
> believe these changes affect the CMake output to actually build things.
> I've also enabled the use of make-tap-reg.py for creating the tap register
> functions which seems to work.

Sounds good to me. UseMakeDissectorReg.cmake only implements the python version,
no idea why I implemented the shell version in UseMakeTapReg.cmake.

> Problems I have seen \ am stuck with:

Again vs specific or with nmake as well?

>    - epan generated files always get rebuilt, e.g. diam_dict.c and the like
>    - epan won't create register.c, make-dissector-reg.py complains about a
>    missing file, from the output the filename looks odd, I suspect I'm hitting
>    some command line limit:
>
> 1>  Generating register.c
> 1>  Registering 1151 files, 0 cached
> 1>  Traceback (most recent call last):
> 1>    File "E:/Wireshark/trunk/tools/make-dissector-reg.py", line 126, in
> <module>
> 1>      file = open(filename)
> 1>  IOError: [Errno 2] No such file or directory:
> 'E:/Wireshark/trunk/epan\\dissectos/packet-dua.c'
> 1>C:\Program Files
> (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error
> MSB6006: "cmd.exe" exited with code 1.

That's again interesting. It works for me using cmd (on Win7). I'm not so sure
about the source of the problem. What do you get when you
dir E:/Wireshark/trunk/epan\\dissectos/packet-dua.c
Ah, forget it: Where does the spelling dissectos come from?

>    -  gtkui won't build with GTK3, missing the pango includes:
> 1>e:\Wireshark\wireshark-win32-libs\gtk3\include\gtk-3.0\gdk/gdktypes.h(35):
>    fatal error C1083: Cannot open include file: 'pango/pango.h': No such file
>    or directory

Yes, that's one of my priority items right now (getting all the libs detected
and working). The most promising approach will be to use pkg-config (from cygwin
for now unless I fail to get that working).

>    - There are the dumpabi projects that I'm not sure are needed for win32;
>    dumpabi, dumpabi-libwireshark, dumpabi-libwiretap, dumpabi-libwsutil.
>    - My final score on the projects in the solution is:
>
> E:\Wireshark\build>dir /s /w *.exe
>  Directory of E:\Wireshark\build\Debug
> capinfos.exe     dumpcap.exe      editcap.exe      mergecap.exe
> randpkt.exe      reordercap.exe   text2pcap.exe
>  Directory of E:\Wireshark\build\tools\lemon\Debug
> lemon.exe
>
> E:\Wireshark\build>dir /s /w *.dll
>  Directory of E:\Wireshark\build\lib\Debug
> wiretap.dll   wsutil.dll
>
> E:\Wireshark\build>dir /s /w *.lib
>  Directory of E:\Wireshark\build\Debug
> capinfos.lib     editcap.lib      mergecap.lib     reordercap.lib
>  Directory of E:\Wireshark\build\lib\Debug
> codecs.lib    gtkui.lib     ui.lib        wiretap.lib   wsutil.lib

That only means it won't get boring during the next few weeks ;-)

Ciao
   Jörg

-- 
Joerg Mayer                                           <jmayer () loplof de>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___________________________________________________________________________
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