[all-commits] [llvm/llvm-project] f626a3: [libc] Codify header inclusion policy (#87017)
Nick Desaulniers via All-commits
all-commits at lists.llvm.org
Thu Apr 11 10:12:20 PDT 2024
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: f626a35086d90f25986e3f06e01a54cca91250d8
https://github.com/llvm/llvm-project/commit/f626a35086d90f25986e3f06e01a54cca91250d8
Author: Nick Desaulniers <nickdesaulniers at users.noreply.github.com>
Date: 2024-04-11 (Thu, 11 Apr 2024)
Changed paths:
M libc/docs/dev/code_style.rst
M libc/docs/usage_modes.rst
M libc/hdr/CMakeLists.txt
A libc/hdr/types/CMakeLists.txt
A libc/hdr/types/sigset_t.h
A libc/hdr/types/struct_epoll_event.h
A libc/hdr/types/struct_timespec.h
M libc/src/signal/linux/CMakeLists.txt
M libc/src/signal/linux/raise.cpp
M libc/src/signal/linux/sigaction.cpp
M libc/src/signal/linux/sigaddset.cpp
M libc/src/signal/linux/sigdelset.cpp
M libc/src/signal/linux/sigfillset.cpp
M libc/src/signal/linux/signal_utils.h
M libc/src/signal/linux/sigprocmask.cpp
M libc/src/signal/sigaddset.h
M libc/src/signal/sigdelset.h
M libc/src/signal/sigemptyset.h
M libc/src/signal/sigfillset.h
M libc/src/signal/sigprocmask.h
M libc/src/sys/epoll/epoll_pwait.h
M libc/src/sys/epoll/epoll_pwait2.h
M libc/src/sys/epoll/epoll_wait.h
M libc/src/sys/epoll/linux/CMakeLists.txt
M libc/src/sys/epoll/linux/epoll_pwait.cpp
M libc/src/sys/epoll/linux/epoll_pwait2.cpp
M libc/src/sys/epoll/linux/epoll_wait.cpp
M libc/src/sys/select/linux/select.cpp
M utils/bazel/llvm-project-overlay/libc/BUILD.bazel
Log Message:
-----------
[libc] Codify header inclusion policy (#87017)
When supporting "overlay" vs "fullbuild" modes, "what ABI are you
using?" becomes a fundamental question to have concrete answers for.
Overlay mode MUST match the ABI of the system being overlayed onto;
fullbuild more flexible (the only system ABI relevant is the OS kernel).
When implementing llvm-libc we generally prefer the include-what-you use
style of avoiding transitive dependencies (since that makes refactoring
headers more painful, and slows down build times). So what header do you
include for any given type or function declaration? For any given
userspace program, the answer is straightforward. But for llvm-libc
which is trying to support multiple ABIs (at least one per
configuration), the answer is perhaps less clear.
This proposal seeks to add one layer of indirection relative to what's
being done today.
It then converts users of sigset_t and struct epoll_event and the epoll
implemenations over to this convention as an example.
To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications
More information about the All-commits
mailing list