[PATCH] D135245: [clang][Tooling] Move STL recognizer to its own library
Kadir Cetinkaya via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Oct 6 00:51:28 PDT 2022
kadircet marked 2 inline comments as done.
kadircet added inline comments.
================
Comment at: clang-tools-extra/clangd/CMakeLists.txt:163
clangToolingInclusions
+ clangToolingInclusionsSTL
clangToolingSyntax
----------------
sammccall wrote:
> StandardLibrary or Stdlib?
>
> STL isn't accurate or consistent with the names in the code.
changing to Stdlib
================
Comment at: clang/lib/Tooling/Inclusions/STL/CMakeLists.txt:2
+add_clang_library(clangToolingInclusionsSTL
+ StandardLibrary.cpp
+
----------------
sammccall wrote:
> This means the implementation files and the header files have a different directory structure, which may be confusing to people trying to work out which library to link against based on the headers they included.
>
> On the other hand, I think the cascading effect of dependencies => libraries => directory structure => header structure is pretty unfortunate leaking of llvm's sad cmake structure. Up to you
>
>
right, i was also torn between moving the headers around vs not. but i finally managed to convince myself that the implementation being in a different subdirectory is actually an unfortunate detail about the way LLVM is build (I didn't want to have PARTIAL_SOURCES_INTENDED, either) and shouldn't matter for the applications that want to use it.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D135245/new/
https://reviews.llvm.org/D135245
More information about the cfe-commits
mailing list