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

libbpf-cargo: Remove clang version check logic #1057

Merged
merged 1 commit into from
Jan 16, 2025

Conversation

d-e-s-o
Copy link
Collaborator

@d-e-s-o d-e-s-o commented Jan 16, 2025

Remove the logic for checking the clang version in use. This logic is worrisome and insufficient for a couple of reasons.

It is insufficient, because we don't actually know what clang version we require -- that is a moving target. Nobody is actively testing against the lowest supported clang version to make sure that our stuff actually works with it. At this point, the stated minimum of 10.0.0 is also increasingly unlikely to be found in the wild, rendering the check less and less useful with every passing year. Ultimately, if a necessary feature really is not available, one would hope that the emitted error isn't too cryptic for anybody to make sense of it.

On the "worrisome" front, the over reliance on anything and everything clang (not just with this check, but with naming more generally) boxes us into a single-compiler world. It is entirely conceivable that a GCC BPF backend arrives eventually (has it already?), which, if past is any guidance, shoulder understand roughly the same arguments as clang itself and, hence, potentially being a drop-in replacement. We should be ready to support this future without shenanigans such as "gcc" being passed to an API asking for "clang". Furthermore, parsing the compiler's output using regular expressions is at best a fragile endeavor. What's more, the amount of dependencies (direct + transitive) pulled in just in service of this one feature is penalizing everybody, for no obvious value-add.
Lastly, the plumping necessary for this feature is part of the reason we have nonsensical call sites such as the following to deal with:

     make(
       true,
       Some(&cargo_toml),
       None,
       Vec::new(),
       true,
       true,
       Vec::new(),
       None,
     )

In short, removal of this checking logic is our best option. Take it.

Remove the logic for checking the clang version in use. This logic is
worrisome and insufficient for a couple of reasons.
It is insufficient, because we don't actually know what clang version we
require -- that is a moving target. Nobody is actively testing against
the lowest supported clang version to make sure that our stuff actually
works with it. At this point, the stated minimum of 10.0.0 is also
increasingly unlikely to be found in the wild, rendering the check less
and less useful with every passing year. Ultimately, if a necessary
feature really is not available, one would hope that the emitted error
isn't too cryptic for anybody to make sense of it.
On the "worrisome" front, the over reliance on anything and everything
clang (not just with this check, but with naming more generally) boxes
us into a single-compiler world. It is entirely conceivable that a GCC
BPF backend arrives eventually (has it already?), which, if past is any
guidance, shoulder understand roughly the same arguments as clang
itself and, hence, potentially being a drop-in replacement. We should be
ready to support this future without shenanigans such as "gcc" being
passed to an API asking for "clang". Furthermore, parsing the compiler's
output using regular expressions is at best a fragile endeavor.
What's more, the amount of dependencies (direct + transitive) pulled in
just in service of this one feature is penalizing everybody, for no
obvious value-add.
Lastly, the plumping necessary for this feature is part of the reason we
have nonsensical call sites such as the following to deal with:
     make(
       true,
       Some(&cargo_toml),
       None,
       Vec::new(),
       true,
       true,
       Vec::new(),
       None,
     )

In short, removal of this checking logic is our best option. Take it.

Signed-off-by: Daniel Müller <deso@posteo.net>
@d-e-s-o d-e-s-o merged commit fce63d8 into libbpf:master Jan 16, 2025
11 of 13 checks passed
@d-e-s-o d-e-s-o deleted the topic/version-check branch January 16, 2025 00:14
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

Successfully merging this pull request may close these issues.

1 participant