On Thu, 2019-04-25 at 14:38 -0700, Richard Smith wrote: > > How can I tell clang to just ignore the GCC-specific precompiled > > headers, or equivalently ignore precompiled headers altogether? I > > can't delete the gch directories because I need them for my build. I've > > read through the clang docs and can't find any likely-looking options. > > > > It's really frustrating when clang tries to appropriate GCC-specific > > options and configurations when it's not actually compatible with them. > > It makes modern multi-compiler development so unnecessarily difficult. > > Sorry about that. Clang is trying to be a transparent drop-in > replacement for build systems that are designed for GCC, and that > means that -include needs to automatically pick up a corresponding > .pch / .gch file if a prior build step put one there. Unfortunately > we don't do any validation to check whether that's Clang's file or > one generated by GCC at that layer :(
Thanks for the response! > You can work around this by using "-Xclang -include -Xclang > foo_pch.h" instead of "-include foo_pch.h"; that will bypass the > driver logic that tries to convert -include to -include-pch. I guess I should be more clear about what I'm doing: my software builds with GCC, but I'm using ccls https://github.com/MaskRay/ccls as an LSP server, which is built on libLLVM. My project also uses CMake, and I generate compile_commands.json to make the compiler command line options available to ccls. As a result, I have very little ability to modify the command line arguments used by libLLVM to parse my source code. The ones in compile_commands.json obviously must be valid GCC command line arguments, so I can't add things like -Xclang. I can add extra arguments to the ccls command line (but just injected into the beginning of the command line, I can't insert them wherever I want) and I can remove specific individual flags (but not groups of flags), but that's about it. This is all great, but now people are hoping to reduce compile times by introducing PCH into our build system. After we do this, I can no longer use ccls because it immediately bails out when trying to parse my files, as it discovers and fails to parse the GCC PCH files. I filed https://bugs.llvm.org/show_bug.cgi?id=41579 in hopes someone can address this. I also discovered this bug filed against clang back in 2014: https://bugs.llvm.org/show_bug.cgi?id=21174 I am looking into taking advantage of this difference in behavior between clang and GCC to solve my problem: I'm putting the GCC PCH files "somewhere else" and adding the "somewhere else" as an -iquote option to my compile line (to ensure that it's searched first before anywhere else). This requires a carefully constructed tower of hacks which makes me unhappy, but it does so far appear to be working (early days in testing yet): GCC will locate the PCH files in the -iquote directory and clang will ignore them. Hopefully, someone won't fix bug #21174 without first resolving my issue #41579 somehow :p :). > Also, -include=foo_pch.h won't do what you think: In my example I wasn't using -include=foo_pch.h, I was using --include=foo_pch.h My understanding is the GCC (and clang according to its docs) will DTRT if you use --include rather than -include: https://clang.llvm.org/docs/ClangCommandLineReference.html -include<file>, --include<file>, --include=<arg> Include file before parsing _______________________________________________ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
