Libbpf is used by xtasks, in the command, ensure that the submodules
are initialized. This eases the user-experience so that users don't
need to think about the submodule, while retaining all the benefits
of using a submodule vs forcing the user to manually check out libbpf
and stick it in some pre-defined place.
We use the symbol pointing to libbpf in xtask in the build script
to avoid repeating this constant.
Also, we install git in the vm so that we can init the submodule
when we build in the vm.
Emit "cargo:rerun-if-changed={}" for each transitive dependency on
integration-ebpf. In a normal world we'd just add integration-ebpf to
our build-dependencies, but cargo ignores this because integration-ebpf
has no library targets.
Use the environment variable AYA_BUILD_INTEGRATION_BPF to indicate to
the build script that it should *actually* build bpf, otherwise emitting
empty files.
This allows metadata builds to skip costly build steps without
sacrificing ergonomics; all compile-time tools such as cargo clippy work
out of the box.
Cargo even gives each of these builds (depending on the value of the
environment variable) its own cache key, so they do not invalidate each
other when the user alternates between metadata and real builds.
This allows the lint action to move out of the VM.
- Add libbpf as a submodule. This prevents having to plumb its location
around (which can't be passed to Cargo build scripts) and also
controls the version against which codegen has run.
- Move bpf written in C to the integration-test crate and define
constants for each probe.
- Remove magic; each C source file must be directly enumerated in the
build script and in lib.rs.
Andrew Werner
Tamir Duberstein