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 somehacksto get there though, patch files attached for others to peruse, as I'mnotsure 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.txtThere 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 forwindows.The windows config.h produced for the normal nmake build is quite abitdifferent than the cmake produced one. I've attached my patch to getthecmake build to work. Folks can check config.h.win32 to see thestartingpoint 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 outevery8192nd byte from the command line passed to make-dissector-reg.py. My patch (make-reg.patch) gets CMake to write out the required sourcefilelist to a file and modifies the python script to read in the file.Thepython 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 itworks 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 willusuallyhave multiple build configurations (Debug, Release, etc.) and thebuildartefacts go in different places depending on the build config used,e.g.builddir\Debug\tshark.exe, builddir\lib\Debug\libwireshark.dll. Asthebuild config is chosen at build time, not cmake generation time thepathsrequired can't be generated by cmake. I think we'll have to move tothenormal 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.80I 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
Current thread:
- Re: Status Cmake Win32 support Graham Bloice (Dec 01)
- <Possible follow-ups>
- Re: Status Cmake Win32 support Graham Bloice (Dec 01)
- Re: Status Cmake Win32 support Joerg Mayer (Dec 02)
- Re: Status Cmake Win32 support Graham Bloice (Dec 02)
- Re: Status Cmake Win32 support Joerg Mayer (Dec 02)
- Re: Status Cmake Win32 support Graham Bloice (Dec 02)
- Re: Status Cmake Win32 support Joerg Mayer (Dec 02)
- Re: Status Cmake Win32 support Guy Harris (Dec 02)
- Re: Status Cmake Win32 support Graham Bloice (Dec 05)
- Re: Status Cmake Win32 support Joerg Mayer (Dec 05)
- Re: Status Cmake Win32 support Guy Harris (Dec 05)
- Re: Status Cmake Win32 support Joerg Mayer (Dec 02)