To find out the current state of the cmake implementation for
Wireshark, please take a look at "What needs to be done?" below.
- Basically this is an experiment and if we find out that it works
- and we like cmake more than autofoo we might switch one day.
Table of contents
=================
-DENABLE_GTK3=OFF
# Build documentation
- -DENABLE_GUIDES=ON
+ -DENABLE_HTML_GUIDES=ON
+ -DENABLE_PDF_GUIDES=ON
# Make ccache and clang work together
-DCMAKE_C_FLAGS='-Qunused-arguments'
# Disable building an application bundle (Wireshark.app) on Mac OS X
-DENABLE_APPLICATION_BUNDLE=OFF
+ # Qt Creator expects .cbp files when used with CMake.
+ -G "CodeBlocks - Unix Makefiles"
+ -G "CodeBlocks - NMake Makefiles"
+
Note 2:
After running cmake, you can always run "make help" to see
a list of all possible make targets.
To get predictable results please set umask explicitly.
How to do an out of tree build using Visual C++ 2013:
-[This is advanced alpha and should build all executables except the GTK3
- Wireshark for 32-bit.]
+[This is at rc status and should build all executables, support for VS2010 and VS2012
+ is included, but hasn't been tested.]
+0) Install cmake (currently 3.1.3 or later is recommended). You can use chocolatey,
+ choco inst cmake.
1) Follow https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html
Steps 1-9
1a) Set the library search path.
- If you set WIRESHARK_LIB_DIR, it will be used as the top-level library
- directory.
If you set WIRESHARK_BASE_DIR,
%WIRESHARK_BASE_DIR%\wireshark-%WIRESHARK_TARGET_PLATFORM%-libs will
be used as the top-level library directory.
+ If you set WIRESHARK_LIB_DIR, it will be used as the top-level library
+ directory. This definition will require changing for different builds (x86 & x64).
1b) set WIRESHARK_TARGET_PLATFORM=win32 (or win64)
-1c) set QT5_BASE_DIR=C:\Qt\5.3\msvc2013_opengl (must match the Qt component path
+1c) set QT5_BASE_DIR=C:\Qt\5.4.1\5.4\msvc2013_opengl (must match the Qt component path
on your system)
-1d) If you want to use Visual Studio make sure that the paths to Python and
- Cygwin are available to GUI applications. The Python path MUST come first.
-2) Install cmake
-2a) Build the zlib library, e.g.
- cd %WIRESHARK_BASE_DIR%\wireshark-%WIRESHARK_TARGET_PLATFORM%-libs\zlib125
- cmake -G "NMake Makefiles" . # msbuild will not do because of configuration path
- cmake --build .
-3) mkdir c:\wireshark\build
-4) cd c:\wireshark\build
-5) Run one of the following to create the build environment:
- cmake -G "NMake Makefiles" path\to\sources (i.e. in case your sources are located at c:\wireshark\trunk, use "..\trunk")
- cmake path\to\sources (this will build for the latest Visual Studio version found)
- cmake -G "Visual Studio 12" ("12" builds for VS2103. Use "11" for VS2012 or "10" for VS2010.)
- cmake -G "Visual Studio 12 Win64" (Win32 is the default)
-6) Run one of the following to build Wireshark:
- nmake /X- VERBOSE=1 (or cmake --build . -- VERBOSE=1 )
+1d) If you want to use Visual Studio to build rather than msbuild from the command line,
+ make sure that the path to Cygwin is available to GUI applications.
+2) mkdir c:\wireshark\build or as appropriate for you.
+ You will need one build directory for each bitness (win32, win64) you wish to build.
+3) cd into the directory from 2) above.
+4) Run the following to generate the build files:
+ cmake -DENABLE_CHM_GUIDES=on xxx path\to\sources
+ where path\to\sources is the absolute or relative path to the wireshark source tree
+ and xxx is replaced with one of the following:
+ nothing - This will build a VS solution for win32 using the latest version of VS found (preferred).
+ -G "Visual Studio 12" ("12" builds for VS2013. Use "11" for VS2012 or "10" for VS2010.)
+ -G "NMake Makefiles" - to build an nmake makefile.
+ -G "Visual Studio 12 Win64" (Win32 is the default)
+5) Run one of the following to build Wireshark:
+ msbuild /m /p:Configuration=RelWithDebInfo wireshark.sln (preferred).
Open Wireshark.sln in Windows Explorer to build in Visual Studio
- msbuild wireshark.sln /m /p:Configuration=RelWithDebInfo
-7) In case you want to test the executable(s) inside the build tree:
- Run setpath.bat whenever it gets updated (there is a message in each cmake
- run whether it is necessary or not).
+ nmake /X- VERBOSE=1 (or cmake --build . -- VERBOSE=1 ) (if you generated nmake files).
+ Subsequent changes to source files and CMakeLists.txt will be automagically detected
+ and new build files generated, i.e. step 4) doesn't need to be run again.
+ Changes to the build environment, e.g. QT_BASE_DIR aren't detected so you must delete the
+ build dir and start form step 2) again.
+6) The executables can be run from the appropriate directory, e.g. run\RelWithDebInfo for VS solutions
+ or run\ for NMake files.
+7) To build an installer, build the nsis_package project, e.g.
+ msbuild /m /p:Configuration=RelWithDebInfo nsis_package.vcxproj
+ nmake ???
Why cmake?
==========
* 64 bit Solaris 10
The Buildbot runs CMake steps on Ubuntu, Win32, Win64, OS X, and Solaris.
+Windows packages are built using CMake steps.
What needs to be done?
======================
installer dmg, RPM, SVR4. This includes setting OS target version stuff
appropriately for OS X. We currently use NSIS for the Windows installer but
should probably use WiX instead.
-- Add back checkAPI target.
- Add support for cmake configurations.
- Automatically figure out if *shark is running from the build directory
(making WIRESHARK_RUN_FROM_BUILD_DIRECTORY unnecessary like it is with
itself. autofoo includes libtool in our case, so what you're running
from the build directory is a script that then runs the executable,
and the executable is in a .libs directory; the code that checks for
- "running from the build directory?" checks for that.
-
- We could perhaps check for the pathname containing "run/", although
- that wouldn't help if we ran it while *in* the "run" directory;
- getting an absolute path for the executable would be necessary for
- that.
+ "running from the build directory?" checks for that. The actual
+ executable isn't supposed to be run directly - it's expected to be run
+ by the wrapper script and might not even work if run directly, as it
+ won't find the relevant shared libraries.
+
+ We could perhaps check for the executable being in a "run" directory
+ instead, if the build drops it there. However, it's possible, at
+ least on OS X, to copy the executable to another directory and have
+ it run, so the guarantee that it's in a "run" directory is not as
+ strong.
- Get plugins loading when running *shark from the build directory.
- That might involve handling ".libs" and "run" differently.
-- Get cross-compilation working (or ensure it does). It works with autofoo.
+ That might involve handling ".libs" and "run" differently. The chance
+ that a random directory the executable was ultimately placed in would
+ be named "run" might also be a bit bigger than the chance that it's
+ named ".libs".
+- Get cross-compilation working (or ensure it does). It works with autofoo--and
+ people use it.
- Handle -DFORTIFY_SOURCE=2 appropriately. (Do a Web search for
"cmake fortify" for some information.)
-- Add support for Visual Studio code anlaysis similar to ENABLE_CODE_ANALYSIS in
- config.nmake.
- Define the GTK_DISABLE_ and GDK_DISABLE_ values as appropriate if we
care about supporting the GTK+ version.
- Install the freedesktop integration files (wireshark.desktop,
git.samba.org / metze / wireshark / wip.git / blobdiff