Home page logo
/

wireshark logo Wireshark mailing list archives

Re: Status Cmake Win32 support
From: Graham Bloice <graham.bloice () trihedral com>
Date: Sun, 1 Dec 2013 17:26:30 +0000

On 30 November 2013 23:18, Joerg Mayer <jmayer () loplof de> wrote:

It took some preparational time before I could test your patches:
- I needed to get a working Windows build first
- I've finally managed to be able to compile via cygwin-ssh, so no more
  remote desktop sessions :-)
- Finish some other small issues first so I didn't have any uncommitted
  stuff in my tree.

On Sun, Nov 24, 2013 at 07:45:07PM +0000, Graham Bloice wrote:
I've now got tshark to build from a VS solution file, had to do some
hacks
to get there though, patch files attached for others to peruse, as I'm
not
sure if they are the optimal solutions:

Before I comment on the individual things in this patch: With your stuff
committed so far I've been able to build on my Windows with both
cmake -> nmake and cmake -> vs (msbuild). Great!

   1. I had to add some MSC version definitions to CMakeLists.txt

There are two independent parts to this patch:

1) I applied the MSC_VER_REQUIRED part (after I understood the cmake
specific
   part of it).

2)
-                       set( CMAKE_PREFIX_PATH
"${QT5_BASE_PATH}\\msvc2010" )
+#                      set( CMAKE_PREFIX_PATH
"${QT5_BASE_PATH}\\msvc2010" )
+                       set( CMAKE_PREFIX_PATH "${QT5_BASE_PATH}" )

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.

   2. I had to remove some definitions from cmakeconfig.h.in for
windows.
   The windows config.h produced for the normal nmake build is quite a
bit
   different than the cmake produced one.  I've attached my patch to get
the
   cmake build to work. Folks can check config.h.win32 to see the
starting
   point for the normal nmake build.

--- cmakeconfig.h.in    (revision 53524)
+++ cmakeconfig.h.in    (working copy)
+#if !defined(_WIN32)
 /* Define to 1 if you have the <stdlib.h> header file. */
 #cmakedefine HAVE_STDLIB_H 1
+#endif

+#if !defined(_WIN32)
 /* Define to 1 if you have the <string.h> header file. */
 #cmakedefine HAVE_STRING_H 1
+#endif

What is the problem here? I only get a warning for these two symbols. Also,
if we do not include kerberos then these symbols will not be defined at
all,
which is also not a good idea. I see two cleaner solutions to this:
- Rename our HAVE_STRING_H to WS_HAVE_STRING_H
- Undef HAVE_STRING_H etc. in the outer file before including the (broken)
includes
  of krb/krb5.h, not without adding a comment about bad taste in putting
the
  values of the included win-mac.h unprotected into a global include file.
I'll probably go with the second one.

   3. As mentioned in my previous message, the VS solution chops out
every
   8192nd byte from the command line passed to make-dissector-reg.py.  My
   patch (make-reg.patch) gets CMake to write out the required source
file
   list to a file and modifies the python script to read in the file.
 The
   python changes *should* be backwards compatible.

I committed your patch but it seems to break on older python. Can you
please take
a look at the OS X buildbot?

   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.

   5. The current setpath method for fixing up paths to all the dll's and
   executables doesn't work for VS solution builds, as a solution will
usually
   have multiple build configurations (Debug, Release, etc.) and the
build
   artefacts go in different places depending on the build config used,
e.g.
   builddir\Debug\tshark.exe, builddir\lib\Debug\libwireshark.dll.  As
the
   build config is chosen at build time, not cmake generation time the
paths
   required can't be generated by cmake.  I think we'll have to move to
the
   normal nmake option of copying everything into a target directory.

I'll look some more into this but it looks doable: After a complete build
with msbuild everything is in ./Debug/ except the dlls, which are in
./lib/Debug/, so I'm optimistic I can find a solution.

   6. I have one warning in the tshark build:

Build succeeded.
       "E:\Wireshark\build\Wireshark.sln" (Executables\tshark target)
(1) ->
       "E:\Wireshark\build\tshark.vcxproj.metaproj" (default target) (2)
->
       "E:\Wireshark\build\tshark.vcxproj" (default target) (16) ->
       (ClCompile target) ->
         ..\trunk\capture-wpcap.c(906): warning C4003: not enough actual
parameters for macro 'G_STRINGIFY_ARG'
[E:\Wireshark\build\tshark.vcxproj]
    1 Warning(s)
    0 Error(s)
Time Elapsed 00:01:26.80

I get that warning as well. It's also happening with cmake/nmake build but
not
with the nmake build. Looking into the source makes it clear: I'll have to
find
a way to determine the value of and assign a value to PCAP_VERSION.

Onwards and upward, now to make dumpcap compile.

This is from svn head, so no extra patches:

C:\wireshark\build\msbuild-x86\Debug>dir *.exe
[...]
30.11.2013  23:49            57.344 capinfos.exe
30.11.2013  23:49            35.840 dftest.exe
30.11.2013  23:49           145.920 dumpcap.exe
30.11.2013  23:49            87.552 editcap.exe
30.11.2013  23:52            47.616 mergecap.exe
30.11.2013  23:54         3.823.616 qtshark.exe
30.11.2013  23:54            35.840 randpkt.exe
30.11.2013  23:54            93.184 rawshark.exe
30.11.2013  23:54            40.448 reordercap.exe
30.11.2013  23:54            78.336 text2pcap.exe
30.11.2013  23:54           385.536 tshark.exe
30.11.2013  23:54         3.016.192 wireshark.exe


Great stuff Joerg, lots to look over here, I had also got wireshark and
qtshark  to build with msbuild.  I've also tried debug and release builds.

I might get some time this evening to go over things, but if I don't I'll
be unable to get back to this for a week as I'm travelling.

Gerald,

We are getting close to a point where CMake is usable for Windows, it would
be nice to have a buildbot for that, keeping the current Win 7 nmake one as
well.  How are we placed for getting a Windows CMake one?
___________________________________________________________________________
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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault