Version info is an aspect of UI implementation so move it to
a more appropriate place, such as ui/. This also helps declutter
the top-level.
A static library is appropriate to encapsulate the dependencies
as private and it is better supported by CMake than object libraries.
Also version_info.h should not be installed as a public header.
We always build the .c files in ui/win32 with Visual C++, so rename
them to .cpp and update CMakeLists.txt to match. Leave the C code mostly
intact for now, but this lets us take advantage of C++ features in the
future if desired.
On macOS with Homebrew, the version is included with the library path.
On updates, the old MAXMINDDB_LIBRARY is invalidated. However
ws_find_package only checks MaxMindDB_LIBRARY. Windows has a similar
problem. Make sure to clear the stale value such that newer versions can
be found, fixing the build.
Fixes#17069
ws_log_domains.h needs to be included before wslog.h to be used
to define WS_LOG_DOMAIN. Also the definition for enum ws_log_level
needs to be exported for other APIs so move that to ws_log_domains.h
and rename the file to ws_log_defs.h to reflect the new scope.
Experience has shown that:
1. The current logging methods are not very reliable or practical.
A logging bitmask makes little sense as the user-facing interface (who
would want debug but not crtical messages for example?); it's
computer-friendly and user-unfriendly. More importantly the console
log level preference is initialized too late in the startup process
to be used for the logging subsystem and that fact raises a number
of annoying and hard-to-fix usability issues.
2. Coding around G_MESSAGES_DEBUG to comply with our log level mask
and not clobber the user's settings or not create unexpected log misses
is unworkable and generally follows the principle of most surprise.
The fact that G_MESSAGES_DEBUG="all" can leak to other programs using
GLib is also annoying.
3. The non-structured GLib logging API is very opinionated and lacks
configurability beyond replacing the log handler.
4. Windows GUI has some special code to attach to a console,
but it would be nice to abstract away the rest under a single
interface.
5. Using this logger seems to be noticeably faster.
Deprecate the console log level preference and extend our API to
implement a log handler in wsutil/wslog.h to provide easy-to-use,
flexible and dependable logging during all execution phases.
Log levels have a hierarchy, from most verbose to least verbose
(debug to error). When a given level is set everything above that
is also enabled.
The log level can be set with an environment variable or a command
line option (parsed as soon as possible but still later than the
environment). The default log level is "message".
Dissector logging is not included because it is not clear what log
domain they should use. An explosion to thousands of domains is
not desirable and putting everything in a single domain is probably
too coarse and noisy. For now I think it makes sense to let them do
their own thing using g_log_default_handler() and continue using the
G_MESSAGES_DEBUG mechanism with specific domains for each individual
dissector.
In the future a mechanism may be added to selectively enable these
domains at runtime while trying to avoid the problems introduced
by G_MESSAGES_DEBUG.
Replace most instances of ws_debug_printf() except in
epan/dissectors and dissector plugins.
Some replacements use printf(), some use ws_debug(), and
some were removed because they were dead or judged to be
temporary.
Currently our build generates very many warnings if
G_DISABLE_ASSERT is defined.
Add ws_assert() and ws_assert_not_reached() to incrementally
replace existing assertions and then disable them using
WS_DISABLE_ASSERT.
Assertions are disabled with CMake build type Release.
By default the build type is RelWithDebInfo so the current
behaviour of enabling assertions by default is (for now) preserved.
Add some notes to README.Developer.
It looks like multi-configuration generators (notably MSBuild) need
Qt autogen properties set on the wireshark target as well as qtui. Do
so unconditionally in both cases. (We were doing so conditionally for
qtui before.)
Set CMAKE_AUTO{MOC,UIC,RCC} if we're running CMake 3.20.0 or 3.20.1 in
order to work around CMake issue 22085, otherwise set the AUTOMOC,
AUTOUIC, and AUTORCC properties for the qtui target. The latter is
preferred since it keeps us from running Qt's meta-object, user
interface, or resource compilers on code outside of ui/qt. Ping #17314.
C-ares has been mandatory since 451a241e50. Remove some checks that are
no longer needed.
Rename OPTIONAL_DLLS to THIRD_PARTY_DLLS and OPTIONAL_PDBS to
THIRD_PARTY_PDBS in CMakeLists.txt, which is more accurate.
When both qt (qt@6) and qt5 are installed via Homebrew, the build fails:
FAILED: ui/qt/CMakeFiles/qtui.dir/qtui_autogen/mocs_compilation.cpp.o
...
In file included from ui/qt/qtui_autogen/mocs_compilation.cpp:2:
In file included from ui/qt/qtui_autogen/EWIEGA46WW/moc_about_dialog.cpp:10:
In file included from ui/qt/qtui_autogen/EWIEGA46WW/../../../../../repos/wireshark/ui/qt/about_dialog.h:15:
In file included from /Users/pwu/repos/wireshark/ui/qt/models/astringlist_list_model.h:15:
In file included from /usr/local/opt/qt5/lib/QtCore.framework/Headers/QAbstractTableModel:1:
In file included from /usr/local/opt/qt5/lib/QtCore.framework/Headers/qabstractitemmodel.h:43:
In file included from /usr/local/include/QtCore/qvariant.h:43:
In file included from /usr/local/include/QtCore/qatomic.h:41:
/usr/local/include/QtCore/qglobal.h:667:26: error: no template named 'enable_if_t' in namespace 'std'; did you mean 'enable_if'?
typename = std::enable_if_t<std::is_arithmetic_v<T> && std::is_arithmetic_v<U> &&
~~~~~^
That qvariant.h header is from Qt 6 which is backwards incompatible:
/usr/local/include/QtCore -> ../Cellar/qt/6.0.2/include/QtCore
It appears that `<qt5 prefix>/include` must be explicitly included as
the default Qt5 include directories does not cover this:
$ find /usr/local -lname '*include/QtCore' -ls
... /usr/local/include/QtCore -> ../Cellar/qt/6.0.2/include/QtCore
$ find /usr/local -name qvariant.h -ls
... /usr/local/Cellar/qt@5/5.15.2/lib/QtCore.framework/Versions/5/Headers/qvariant.h
... /usr/local/Cellar/qt/6.0.2/lib/QtCore.framework/Versions/A/Headers/qvariant.h
$ find /usr/local -name QtCore -lname '*Headers' -ls
... /usr/local/Cellar/qt@5/5.15.2/include/QtCore -> ../lib/QtCore.framework/Headers
... /usr/local/Cellar/qt/6.0.2/include/QtCore -> ../lib/QtCore.framework/Headers
$ ls -la /usr/local/opt/qt5
... /usr/local/opt/qt5 -> ../Cellar/qt@5/5.15.2
As described at
https://medium.com/@alasher/colored-c-compiler-output-with-ninja-clang-gcc-10bfe7f2b949
both Clang and gcc generate colorized output when they detect a
terminal, but not for piped output, which is the case when using Ninja.
Add an ENABLE_COMPILER_COLOR_DIAGNOSTICS CMake option, and set it to
"ON" when we're using Ninja.
In the merge-req:ubuntu-gcc-ctest and merge-req:ubuntu-clang-other-tests
GitLab CI jobs, generate colorized HTML report artifacts using
ansi2html.
Calling cmake with -DENABLE_VLD=ON when building with Visual Studio,
results in debug configuration being linked to Visual Leak Detector.
By default, Visual Leak Detector outputs the leak summary to Visual
Studio debug window. When ENABLE_VLD is active, VLD is linked to all
wireshark libraries and executables.
Sometimes initializing the same field twice indicates a bug, so see
whether we can leave it enabled and suppress the warning in cases where
it's probably not a bug (too bad GCC didn't let you specify a default
initializer with, for example:
int foo[16] = {
[] = 17,
[12] = 34
};
which would mean we wouldn't have to suppress that warning in
ui/text_import.c).
Note also that not all compilers that can produce this warning call the
option "-Woverride-init".
As noted in be2b0fc810, we need to set CMAKE_AUTO* before searching for
Qt packages when using 3.20.0 and later. However, this fails if we're
using CMake 3.9.6 or earlier. Set CMAKE_AUTO* where needed depending on
our CMake version.
Ping #17314.
The distinction between the different kinds of capture utility
may not warrant a special subfolfer for each, and sometimes the
distinction is not be clear or some functions could stradle
multiple "categories" (like capture_ifinfo.[ch]).
Simplify by having only a generic 'capture' subfolder. The
separate CMake libraries are kept as a way to reuse object code
efficiently.
This policy says: "Since version 3.10, CMake processes regular and GENERATED
source files in AUTOMOC and AUTOUIC. In earlier CMake versions, only regular
source files were processed. GENERATED source files were ignored silently."
We are currently running AUTOMOC/RCC/UIC on too many files unnecessarily and
that should be improved. CMake 3.20 introduced some changes related with this
that broke the build (issue #17314) and need further investigation.
Meanwhile setting this policy to NEW shouldn't break anything and silences
some noisy CMake warnings.
Enable CMAKE_AUTOMOC, CMAKE_AUTOUIC, and CMAKE_AUTORCC before searching
for Qt packages. This is apparently required for CMake 3.20.0 and later.
Fixes#17314.
Modularized the parser backend slightly to have the needed hooks
Modified the timestamp format slightly to enable arbitrary postion for
second fractions
Added a regex based seeking parser for textfiles as frontend alternative
to text_import_scanner.l
Regex is using the GLib implementation
Supported frame-data formats are bin, hex, oct and base64
Regex based importing UI
Fixed Meory-leak in ImportTextDialog::exec()
A new tab was added to the text_import ui to accomodate the new fields
Hints are available and styled accordingly
The existing stuff doesn't appear to work (I tried it on 32-bit Ubuntu
18.04, and it did *not* add any flags to the compilation, as it appeared
not to conclude that they were necessary, even though they were).
Pull in the stuff from libpcap, which *does* appear to work. (it does
so in my 32-bit Ubuntu testing).
This should fix#17301.
While we're at it, fix cppcheck.sh so that it doesn't attempt to run
cppcheck on files that have been deleted.
This pull request includes:
* The "Follow DCCP stream" feature.
* Updated docbook documentation for the "Follow DCCP stream" feature.
* Test for the feature.
* Corresponding packet trace for the test.
Increase the minimum required version of Qt from 5.3 to 5.6. The various
Linux distribution versions that shipped with earlier Qt versions (RHEL
6, Fedora 23, openSUSE 13.2, Debian jessie, Ubuntu 16.04) have either
reached end of support or will do so soon.
The official Qt 5.6 releases for macOS require 10.8, so make that the
minimum macOS version.
Remove a bunch of no-longer-needed version checks.
The include_directories documentation at
https://cmake.org/cmake/help/latest/command/include_directories.html
says:
"Note: Prefer the target_include_directories() command to add include
directories to individual targets and optionally propagate/export them
to dependents."
Switch from include_directories to target_include_directories in a bunch
of places.
Add "SYSTEM" to the remaining external include_directories calls in
order to minimize our compiler warning blast radius.
Forcibly unset the cached version of CMAKE_VERBOSE_MAKEFILE if the
FORCE_CMAKE_NINJA_NON_VERBOSE environment variable is set, to make
*extra* sure that we don't do a verbose build.
Visual Studio's code analyzer lets you avoid analyzing external headers
using CAExcludePath. Add a note suggesting that we might want to do this
using the VS_USER_PROPS CMake property, but that for now we're using an
environment variable in the builder config.
Overriding the definition of the rpmbuild macro cmake_build on the
command line, so that it doesn't include the string "--verbose", should
prevent cmake --build from being run with --verbose, and thus prevent it
from running Ninja with the -v flag, and thus prevent a bunch of extra
noisy output from being produced for every build command, and thus
prevent the build log from hitting GitLab's 4MB limit.
Unlike piping the output of "ninja rpm-package" to sed, this means that
the exit status of "ninja rpm-package", rather than the exit status of
sed, is tested.
Filter out the -W and -f options from the output of "ninja rpm-package",
to try to cut down the verbosity.
Do that instead of passing --quiet to rpmbuild, so we get command
progress messages, just without the extra junk.
If the FORCE_CMAKE_NINJA_QUIET environment variable is set, have the
top-level CMakeLists.txt add the -q flag to the arguments to rpmbuild.
That appears to reduce the amount of output.
Set that environment varible in the rpm-fedora build.
João Valverde