cleanup(build): Use a single cmake module for driver_config.h #1188
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gnosek The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
gnosek
force-pushed
the
driver-config-cleanup
branch
from
f49fc4b to
caf09f8
Compare
|
Please double check driver/API_VERSION file. See versioning. /hold |
|
falcosecurity/driverkit#283 fixes driverkit for this PR. |
|
NOTE: since driverkit jobs are not required checks, we can go on with this one. |
|
Let's try for: |
|
@gnosek can you fix other tests ? |
|
/milestone 0.13.0 |
|
Moving to |
The BPF build now no longer touches the source directory and does not depend on any files outside the (generated) source directory. Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Instead of manually generating driver_config.h when needed
(approximately, since the libscap engines do not generate it, even
though they rely on it), encapsulate all the logic in a single
cmake module.
Note: this removes the driver_config directory from
LIBSCAP_INCLUDE_DIRS. If you actually need driver_config.h,
add this to your CMakeLists.txt:
include(driver_config)
include_directories(${DRIVER_CONFIG_OUTPUT_DIR})
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
gnosek
force-pushed
the
driver-config-cleanup
branch
from
caf09f8 to
8962abf
Compare
|
Hi @gnosek just kindly checking in on the status of this PR. When do you all think we should work on it? Thank you! |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
|
@gnosek any update on this? /remove-lifecycle stale |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
|
@gnosek any update on this? do we still want to merge this PR? 🤔 |
|
As you might imagine, this has fallen behind other things in my stack of yaks to shave. Would be nice to have it but I guess I'll redo it from scratch some day. |
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh with Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle rotten |
|
/remove-lifecycle rotten |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
Instead of manually generating driver_config.h when needed (approximately, since the libscap engines do not generate it, even though they rely on it), encapsulate all the logic in a single cmake module.
Note: this removes the driver_config directory from LIBSCAP_INCLUDE_DIRS. If you actually need driver_config.h, add this to your CMakeLists.txt:
What type of PR is this?
/kind cleanup
Any specific area of the project related to this PR?
/area build
/area driver-kmod
/area driver-bpf
/area driver-modern-bpf
What this PR does / why we need it:
driver_config.h is generated in three different places, in different ways, into two target locations (including the source directory). Clean this up and use just one well-defined place we can refer to later.
Also, (as it turned out to be a prerequisite for the fix), the BPF build now no longer touches the source directory and does not depend on any files outside the (generated) source directory.
Does this PR introduce a user-facing change?:
(I'm not sure about user-facing, but it is a change for libscap consumers, even though driver_config.h is generally not needed)