This is a first step towards granularizing <locale>.
Details
- Reviewers
ldionne Mordante - Group Reviewers
Restricted Project - Commits
- rGc847b8e24cfd: [libc++] Make bsd_locale_fallbacks.h modular and move it into…
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/include/CMakeLists.txt | ||
---|---|---|
217 | Granularization patches are usually pretty mechanical because the organization of our headers already makes sense. However, the organization in <locale> makes little sense (at least to me). There's clearly some design trying to emerge, but it seems to have grown in weird ways with time. So I think it is worth designing how we want the organization to look like. I suggest: __locale_dir/ locale_base_api/ bsd_locale_defaults.h // bsd_locale_fallbacks.h // These headers are meant to be included by the per-platform locale_guard.h // shims to provide the BSD-like API that we expect android.h solaris.h [...] freebsd.h locale_base_api.h // This header would contain an #if-else chain that includes the // appropriate shims for the current platform. It would also document // what base API a new platform has to support for libc++ to support // <locale>, which is kind of missing right now. scan_keyword.h [...] Then, in <locale> we would include <__locale_dir/shims.h> and we would be guaranteed to have a BSD-like API available. This patch doesn't have to go all the way, but once we agree on the end organization, I would move stuff around in a way that's consistent with where we want to end up. |
Granularization patches are usually pretty mechanical because the organization of our headers already makes sense. However, the organization in <locale> makes little sense (at least to me). There's clearly some design trying to emerge, but it seems to have grown in weird ways with time. So I think it is worth designing how we want the organization to look like. I suggest:
Then, in <locale> we would include <__locale_dir/shims.h> and we would be guaranteed to have a BSD-like API available.
This patch doesn't have to go all the way, but once we agree on the end organization, I would move stuff around in a way that's consistent with where we want to end up.