-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cleanup(build): Use a single cmake module for driver_config.h #1188
base: master
Are you sure you want to change the base?
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 |
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 <[email protected]>
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 <[email protected]>
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)