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

[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

On 12 October 2013 23:38, Joerg Mayer <jmayer@xxxxxxxxx> wrote:

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.

 

From a Visual Studio command prompt (probably the same one you use for nmake)  cause CMake to generate the appropriate output (not passing -G does that for me) then type `msbuild Wireshark.sln`.

 

It's make on steroids, but also works with Visual Studio solutions.  A Visual Studio solution (for 2010 onwards) is a set of xml files.  The .sln file lists all the projects aka targets, and each project file has all the instructions to build that project.

 

>  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.

 

I'll try these changes out on a Linux CMake build to make sure they don't break anything and then commit them.  Should I set UseMakeTapReg to use Python in all platforms or just Windows?

 

> Problems I have seen \ am stuck with:

Again vs specific or with nmake as well?

 

All VS2010 solution. 

>    - 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?

 

I know, it's really odd.  The command in the solution is built correctly.