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.
This adds a new utility called ci/collect-repo-info.py to produce a JSON
document that is then baked into the Zeek executable file. Further, when
creating a tarball via `make dist`, put a top-level repo-info.json file
in place that is picked when no .git directory exists.
Closes#1405
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.)
As initial examples, this branch ports the Syslog and Finger analyzers
over. We leave the old analyzers in place for now and activate them
iff we compile without any Spicy.
Needs `zeek-spicy-infra` branches in `spicy/`, `spicy-plugin/`,
`CMake/`, and `zeek/zeek-testing-private`.
Note that the analyzer events remain associated with the Spicy plugin
for now: that's where they will show up with `-NN`, and also inside
the Zeekygen documentation.
We switch CMake over to linking the runtime library into the plugin,
vs. at the top-level through object libraries.
MSVC uses _DEBUG, unlike all of the other compilers, so we aren't
properly enabling/disabling varying bits of code that are dependent
on DEBUG being defined.
- 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
For generators like Makefile the implicit dependency would not have been
apparent to `make` which could have lead to build failures (depending on
the way targets were scheduled). This patch makes the dependency
explicit so it can be enforced.
Closes#2586.
This has come up a few times and the motivation is mainly better "first timer"
experience with Zeek. Concretely, if one wants to run a Zeek cluster with
multiple workers and reasonable load balancing on Linux, AF_PACKET is a decent
start. Without AF_PACKET support being built into Zeek, however, a new user's
next experience is that of setting up a development environment in order
to compile an external plugin (think compiler, kernel headers, zkg, ...).
Only to get what could be termed basic functionality.
This is using the ZEEK_INCLUDE_PLUGINS infrastructure. I've used the all
upper case spelling of AF_PACKET in the help output because it seems everyone
else references/writes it like that. I think we should also write it
like that in the docs.
We already added the toplevel build dir to the paths exposed by
`build/zeek-path-dev`, but never made the matching change for
`build/zeek-path-dev.[sh,csh]`. Due to that a shell would have never
found `zeek-config` from the build env like it would have been found for
installations, and could potentially even have picked up a different
one.
spicy-plugin can find Spicy in paths given by `SPICY_ROOT_DIR` while
`./configure` instead set `SPICY_ROOT`. With this patch we now set the
correct variable.
We also adjust variations of the previous variable name with different
capitalization which caused us to not properly configure spicy-plugin
(which triggers finding Spicy in its given prefix).
Closes#2363.
This adds https://github.com/gulrak/filesystem as a submodule into auxil
as a compiler-independent std::filesystem replacement.
The ghc::filesystem namespace is exposed as zeek::filesystem in util.h.
In the build directory, we add 3rdparty/ghc as a symlink to auxil in
order to support building from the build tree.
<build_dir>/src/3rdparty/ghc -> /path/to/zeek/src/auxil/filesystem/include/ghc
In the installation tree, the headers are installed into include/zeek/3rdparty:
<install_dir>/include/zeek/3rdparty/ghc
Note, this differs from how we approached rapidjson which isn't included
using a zeek/3rdparty and instead requires an additional include path of
the following form for external plugins to find and use it.
<install_dir>/include/zeek/3rdparty/rapidjson/include/
We diverge from this approach. Placing ghc directly into 3rdparty appears
nicer and avoids changing external components (DynamicPlugin.cmake / spicyc)
The user so far had to configure with --enable-zeek-client to trigger
installation of the client (from auxil/zeek-client). This flips it around to
allow disabling the installation, and removes --enable-zeek-client from the
Docker build in CI, where we've already been using it to allow the cluster
testsuite to run tests with that image.
This establishes several of the Zeek installation's directories in
CMakeLists.txt, and adds a new ZEEK_STATE_DIR (via `configure --state-dir`) for
arbitrary Zeek-related variable state. It defaults to ZEEK_ROOT/var/lib.
This leaves the existing, zeekctl-related ZEEK_LOCAL_STATE_DIR unchanged and
does not use it. We'll likely deprecate it when removal of zeekctl approaches.
We previously only generated these files if configuring a build which
included Spicy. This meant that e.g., `zeek-path-dev.*` scripts would
emit errors for non-existing paths if Spicy was not included.
We now always generate the helper scripts so we can reference them
regardless of build configuration. If Spicy is not included the files
will still be sourced, but have no actual effect.
If e.g., optional dependencies are installed in the same prefix as a
previous Zeek installation, the build would have previously found
`zeek-config.h` from the external prefix instead of from the current
build.
With this patch we now include the current binary dir before any
previously configured include directories (here in particular: optional
dependencies). With that the correct `zeek-config.h` is found.
This separates Gen-ZAM from the main Zeek distribution and places it in a
submodule at auxil/gen-zam, reflecting binpac and bifcl. Configuring with
--with-gen-zam=... allws reuse of an existing executable.
