Skip to content
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

Remove public feature flags #57

Open
bnaecker opened this issue Apr 14, 2022 · 1 comment
Open

Remove public feature flags #57

bnaecker opened this issue Apr 14, 2022 · 1 comment

Comments

@bnaecker
Copy link
Collaborator

The current implementation of usdt (v0.3.2) uses the public feature flag "asm" to decide what code to generate inside the probe macros. We initially did this for a few reasons. First, the Rust asm feature was required, and it's pretty common practice to gate nightly features in a crate with a public feature flag. Secondly, it was very useful for development to pick a real or no-op implementation of the probes.

The time has come to remove this feature flag, however. The asm feature has been stabilized. The asm_sym feature, required for macOS, is on the path to stabilization. More importantly, a feature flag for this doesn't make a whole lot of sense. First, the "real" version of the probes is the whole point of the crate, so turning them off seems silly. Second, feature flags are additive, which I didn't quite appreciate when I built it this way initially. This is a big problem, since it means it's possible for trouble when crate uses two other crates, both of which use usdt. If one enables the probes, it doesn't matter whether the other crate chose to enable them, the probes are there due to feature unification.

This issue tracks removing all public feature flags. The crate will choose the code to be generated in the probe macros solely on the basis of the target OS.

@bnaecker
Copy link
Collaborator Author

bnaecker commented Jan 8, 2024

It may be a good time to tackle this. The last feature we really need, asm_sym, stabilized some time ago. If we're willing to push the MSRV to 1.66, then we can use a stable toolchain on all supported platforms and avoid any nightly messiness or feature checks. That MSRV is not too far away from the 1.65 currently implied by some of our dependencies. (E.g., see this checksuite run.)

It would be very nice to get rid of all that cruft and the attendant build.rs files. 1.66 is pretty old now, so this feels like a reasonable choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant