On Sat, Oct 12, 2013 at 07:31:27PM +0100, Graham Bloice wrote:
> On 11 October 2013 16:09, Joerg Mayer <jmayer@xxxxxxxxx> 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@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.
