stream: clean up reassembly table.
[metze/wireshark/wip.git] / README.cmake
index 41edb8ad72fb2a9112c18207313a7b29a24ff621..645cfd67c4ae60207ed09f5d3fe8ada7ee27979f 100644 (file)
@@ -36,7 +36,7 @@ Note 1:
   In step 5) you may need to override the defaults for features. Common
   options include:
 
-  # Disable the POSIX capbabilities check
+  # Disable the POSIX capabilities check
   -DENABLE_CAP=OFF
 
   # Enable debugging symbols
@@ -57,13 +57,18 @@ Note 1:
   # http://public.kitware.com/Bug/view.php?id=13818
   -DPYTHON_EXECUTABLE=c:/Python27/python
 
-  # Disable building an application bundle (Wireshark.app) on Mac OS X
+  # Disable building an application bundle (Wireshark.app) on OS X
   -DENABLE_APPLICATION_BUNDLE=OFF
 
   # Qt Creator expects .cbp files when used with CMake.
   -G "CodeBlocks - Unix Makefiles"
   -G "CodeBlocks - NMake Makefiles"
 
+  # We call try_compile many times, particularly via ConfigureChecks.cmake.
+  # Setting a lightweight try_compile configuration can speed up cmake,
+  # particularly for MSBuild.
+  -DCMAKE_TRY_COMPILE_CONFIGURATION=Release
+
 Note 2:
   After running cmake, you can always run "make help" to see
   a list of all possible make targets.
@@ -74,7 +79,7 @@ Note 3:
   To get predictable results please set umask explicitly.
 
 How to do an out of tree build using Visual C++ 2013:
-[This is at rc status and should build all executables, support for VS2010 and VS2012
+[This is used for the 2.x release builds, 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.
@@ -90,20 +95,18 @@ How to do an out of tree build using Visual C++ 2013:
 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 to build rather than msbuild from the command line,
-    make sure that the paths to Python and Cygwin are available to GUI applications.
-    The Python path MUST come first.
+    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 -DPYTHON_EXECUTABLE=/path/to/python -DENABLE_CHM_GUIDES=on xxx path\to\sources
-   where /path/to/python is the path to your Windows python executable, e.g. C:/Python27/python
-   and path\to\sources is the absolute or relative path to the wireshark source tree
+   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)
+       -G "Visual Studio 12 Win64" (to build an x64 version you must add the "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
@@ -114,7 +117,11 @@ How to do an out of tree build using Visual C++ 2013:
    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.
+   On macOS CMake creates an application bundle by default and places executables in
+   run/Wireshark.app/Contents/MacOS. It also creates a convenience wrapper script
+   (run/wireshark) which will run the Wireshark executable in the bundle.
+7) To build an installer, build the nsis_package_prep and then the nsis_package projects, e.g.
+   msbuild /m /p:Configuration=RelWithDebInfo nsis_package_prep.vcxproj
    msbuild /m /p:Configuration=RelWithDebInfo nsis_package.vcxproj
    nmake ???
 
@@ -122,10 +129,11 @@ Why cmake?
 ==========
 - Can create project files for many IDEs including Qt Creator, Visual Studio,
   and XCode.
-- Fast
+- Fast, builds in parallel in Visual Studio or msbuild with the /m flag
 - Easier to understand/learn
 - Doesn't create any files in the source tree in case of out of tree builds
 - One build infrastructure for all of our tier 1 platforms (including Windows)
+- Out of tree builds permits both Win32 and Win64 builds without requiring a "clean" when swapping.
 
 Why not cmake?
 ==============
@@ -169,41 +177,12 @@ What needs to be done?
   appropriately for OS X. We currently use NSIS for the Windows installer but
   should probably use WiX instead.
 - 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
-  autofoo).
-  Sadly:
-
-      $ file run/qtshark
-      run/qtshark: Mach-O 64-bit x86_64 executable
-
-  so what you're running from the build directory is the executable
-  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.  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.  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.)
 - 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,
-  wireshark-mime-package.xml, etc.).
 ...
 
 Links regarding cmake