Add a define for `ZEEK_CONFIG_SKIP_VERSION_H` to static plugins as well
as to dynamic plugins that we build alongside Zeek. When including
`zeek-config.h` with this macro defined, the header skips including
`zeek-version.h`.
When bumping the VERSION file, everything that includes the auto-generated
zeek/zeek-config.h needs to rebuild and ccache usage is voided due the file
changing. Split the mutable version information into a new zeek-version.h
file to avoid this.
Further, do not include zeek-version.h within Plugin.h and avoid the reference
to ZEEK_VERSION_FUNCTION unless we're building an external plugin.
Closes#2776.
We previously used the Spicy plugin's `Spicy::available` to test for
Spicy support. However, having Spicy support does not necessarily mean that we
have built Zeek with its in-tree Spicy analyzers: the Spicy plugin
could have been pulled in from external. The new BIF now reliably
tells us whether the Spicy analyzers are available; its result
corresponds to what `zeek-config --have-spicy-analyzers` returns as
well.
We also move the two current checks over to use this BIF.
(Note: I refrained from renaming the CMake-side `USE_SPICY_ANALYERS`
to `HAVE_SPICY_ANALYZERS`. We should do this eventually for
consistency, but I didn't want to make more changes than necessary
right now.)
- Ignore conan libpcap if PCAP_ROOT_DIR is passed
- Update the cmake submodule to pick up changes for finding the right
paths to npcap
- Add lazy-loading of npcap so the library path gets set correctly
at startup
Due to a bug (or intentional code) in SQLite, we disabled enabling the shared cache
in sqlite3 if running under ThreadSanitizer (see cf1fefbe0b0a6163b389cc92b5a6878c7fc95f1f).
Unfortunately, this has the side-effect of breaking the simultaneous-writes test because
the shared cache is disabled. This is hopefully a temporary fix until SQLite fixes the
issue on their side.
There's a known false positive with the atomic variables in this method
that triggers a complaint from ThreadSanitizer. Marking it as ignored
avoids the warning.
This is the result of (major * 10000 + minor * 100 + patch), for example
3.1.2 becomes 30102. This definition may be helpful for external code
that requires conditional compilation to support multiple Zeek
versions with differing APIs.
Plugins that were made using an older skeleton (e.g. from Bro 2.5.x)
may still reference "bro-config.h", "bro-path-dev", or "bro" from the
build tree, so we can simply provide compatibility symlinks/wrappers
for the new files that use "zeek" in their names.
Most of these changes are either cmake-related or plugin-related.
Added a new test "plugins/legacy.zeek" to test that legacy Bro plugins
still work.
Also added a symlink bro-path-dev.in because some legacy Bro packages
won't install without it.
This also installs symlinks from "zeek" and "bro-config" to a wrapper
script that prints a deprecation warning.
The btests pass, but this is still WIP. broctl renaming is still
missing.
#239
