facebookexperimental / facebookexperimental/libunifex
io_uring.h is included in a public interface header file
- Dominant language
- C++
- Stars
- 1.7k
- Forks
- 210
- PR merge metrics
- No merged PRs in 30d
Description
Right now libunifex includes `io_uring.h` in a public interface header file, and requires cmake targets consuming libunifex to include liburing. liburing is not a commonly installed library, plus it is currently undergoing rapid development, so doing this is somewhat anti-social to quick and easy use of libunifex.
Suggested solutions in order of my personal preference:
1. Personally speaking, I think it is very doable that use of liburing can be kept exclusively internal to source files, and not be required in header files. You just need to reorganise your implementation a bit. Where I'd like to reach is the ability to ship precompiled binaries and a set of headers without imposing extra install steps upon end users.
2. You can replicate the bare minimum necessary of liburing into public header files, and run a series of static asserts in the source files to ensure that your replicated edition is binary compatible with latest liburing. I've been known to do this in my own code from time to time, and for kernel APIs, maintenance burden is generally excellent.
3. You can bundle a copy of liburing in with libunifex, either directly as source, or via a git submodule.
4. Finally, you can leave things as they currently are, where you silently disable io uring support if the end user hasn't installed liburing. I greatly dislike this choice.
This is really a question of direction, which you guys need to choose. I raise this now before we dig a deeper i/o uring packaging hole.
Contributor guide
Assessment
This issue has not been assessed yet.