https://cmake.org/cmake/help/latest/release/3.25.html says:
"On Windows, when targeting the MSVC ABI, the find_library() command now
accepts .a file names after first considering .lib. This is symmetric
with existing behavior when targeting the GNU ABI, in which the command
accepts .lib file names after first considering .a."
If "MSVC" is defined, only search for libsmi-2. This keeps us from finding
libsmi.a. Set NO_SYSTEM_ENVIRONMENT_PATH when we're searching for zlib. This
keeps us from finding Strawberry Perl's version.
Some SpanDSP builds link with LibTIFF, but our Windows version doesn't.
Switch to the name "Logray" for the log analyzer. Rays are biological
cousins of sharks and more people like the name "Logray" in a completely
unscientific survey here. Apologies for any inconvenience this might
cause.
Add a FindSinsp CMake module, and use it in the Sysdig Bridge plugin
CMakeLists.txt. It still needs work, but should at least be usable on
more machines.
Conflicts:
plugins/epan/sysdig_bridge/CMakeLists.txt
The Sparkle project recently released Sparkle 2.0.0, which deprecates
the version 1 API. Add version discovery to FindSparkle.cmake and
require version 1 until we add support for the new API. Ping #17861.
Repeated words were found with:
egrep "(\b[a-zA-Z]+) +\1\b" . -Ir
and then manually reviewed.
Non-displayed strings (e.g., in comments)
were also corrected, to ease future review.
PCRE2 is the future of PCRE. The only advantage of GRegex is that
it comes bundled with GLib, which is not an advantage at all.
PCRE2 is widely available, the GRegex abstractions layer are not a
good fit and abstract things that don't need abstracting or that we
could handle better ourselves, there are open bugs (#12997) and
maintenance is spotty at best.
GRegex comes with many of the problems of bundled code, aggravated by
the fact that it completely falls outside of our control.
CMake does not use any shell to run execute_process(). When
running asciidoctor we must use the batch file. Put that before
"asciidoctor" (a ruby script) so CMake uses that instead.
Remove the generate_*_pages targets that were recently introduced,
since they're not really needed. Only add the "manpages" target
if we have Asciidoctor.
Asciidoctor lets us generate multiple documents at once, so do so for
our man pages. If we're using AsciidoctorJ this minimizes the number
of JVM instances we have to spin up. This reduces the build time on my
Windows VM here quite a bit, and will hopefully do so on the CI builders.
Add a .editorconfig file in cmake/modules.
Depend on our generator targets instead of the generated files, which
allows parallel builds outside of Ninja. Don't reserve JRE memory when
building HTML and man page targets. This reduces the "docs" target build
time on my Windows VM here from over two minutes to under one.
Convert doc/*.pod to Asciidoctor. This:
* Means we use the same markup for our man pages, the guides, and
release notes.
* Lets us add versions to our man pages.
* Gives us more formatting options, e.g. AsciiDoc supports `commands`,
nested lists and makes it easy to include version information. The
manpage backend doesn't seem to support tables very well,
unfortunately.
Convert our CMake configuration to produce *roff and html man pages
using Asciidoctor. Add a "manarg" block macro which makes our synopses
wrap correctly.
Similar to the release notes, guides, and FAQ, if Asciidoctor isn't
found the man pages won't be generated or installed.
Move Asciidoctor to the list of package build dependencies in various
places.
This commit includes the conversion script (pod2adoc.py), which will be
removed later.
Line count sanity check:
Man page .pod .adoc
androiddump 260 280
asn2deb 93 105
capinfos 401 471
captype 54 55
ciscodump 241 269
dftest 42 42
dpauxmon 153 169
dumpcap 464 534
editcap 528 583
etwdump 136 156
extcap 157 181
idl2deb 91 103
idl2wrs 120 100
mergecap 206 207
mmdbresolve 75 75
randpkt 107 111
randpktdump 158 184
rawshark 558 610
reordercap 76 78
sdjournal 145 157
sshdump 272 302
text2pcap 274 312
tshark 2135 2360
udpdump 133 151
wireshark-filter 486 479
wireshark 2967 3420
If we are using MSYS2 we use those packages to build Wireshark
using MinGW-w64 and disable most or all of our win-setup.ps1 codepaths.
Fix GLib configuration. Disable copying of DLLs with MSYS2.
Some tests in the suite_capture test suite are failing with MSYS
MINGW64. That particular set of tests is way too brittle regarding
file system paths; more work is needed to improve that situation.
Reverse the text added in cdd6f2ec80 and note that we can't yet use
Asciidoctor.js to build our documentation. I'm not sure how I managed to
miss this in my initial tests, but Asciidoctor.js is missing Docbook,
PDF, and EPUB backends, and doesn't support Ruby macros.
If a macro identifier is not defined it evaluates to zero in an
expression, so the outer #ifdef is unnecessary and should be
avoided (the less the better).
Add a missing CMake comment while here.
Wireshark fails to build when cross-compiling on Gentoo/ChromeOS
systems because the lemon command is not properly specified or
included in PATH, failing with:
/bin/sh: lemon: command not found
The relevant excerpt from build.ninja is:
COMMAND = cd ..._build/plugins/epan/mate && lemon -T.../tools/lemon/lempar.c
-d. .../plugins/epan/mate/mate_grammar.lemon
By specifying the full path to "lemon" we ensure it is
always searched and found in the correct location.
Use an apostrophe instead of RIGHT SINGLE QUOTATION MARK in our PDF and
EPUB filenames. Some programs (notably Okular) can't open filenames with
extended characters, at least on Windows.
We use some private functions from MIT kerberos:
- krb5_free_enc_tkt_part()
- decode_krb5_enc_tkt_part()
- encode_krb5_enc_tkt_part()
but we already do that for krb5int_c_mandatory_cksumtype(),
which is newer than the above functions.
We use all of them only under HAVE_KRB5_PAC_VERIFY,
so we don't seem to need additional configure tests.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
On Windows, search for glibconfig.h in the vcpkg lib directory. Search
for it in the directory that contains libglib-2.0 on other platforms.
Avoid a side effect that caused us to search in `/lib` on non-Windows
platforms. Don't add GLIB2_LIBRARY to the search path -- that contains
the path to a file, not a directory.
Upgrade our vcpkg bundle to one that includes GLib 2.66.4 and libxml2
2.9.10.
Avoid running pkgconfig on Windows so that we don't find Strawberry
Perl's headers.
João Valverde