Rather than including llvm header files piecemeal on an ongoing basis, I'm looking for a way to include all such header files once and for all. To that end, I wrote a Python script to generate include directives for all .h files in llvm/include and its subdirectories. This almost works, but getting two error messages: In file included from src\main.cpp:1: In file included from src/../llvm.h:254: In file included from \llvm\include\llvm/DebugInfo/PDB/ConcreteSymbolEnumerator.h:13: In file included from \llvm\include\llvm/DebugInfo/PDB/IPDBEnumChildren.h:13: \llvm\include\llvm/DebugInfo/PDB/PDBTypes.h(444,3) : error: redefinition of enumerator 'Unknown' Unknown, ^ \llvm\include\llvm/CodeGen/CallingConvLower.h(189,16) : note: previous definition is here typedef enum { Unknown, Prologue, Call } ParmContext; ^ In file included from src\main.cpp:1: In file included from src/../llvm.h:298: In file included from \llvm\include\llvm/DebugInfo/PDB/DIA/DIADataStream.h:13: \llvm\include\llvm/DebugInfo/PDB/DIA/DIASupport.h(30,10) : fatal error: 'cvconst.h' file not found #include <cvconst.h> Are there known fixes for these, or is there something I should be doing differently? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151209/c59266f5/attachment.html>
On Wed, Dec 9, 2015 at 7:11 AM, Russell Wallace via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Rather than including llvm header files piecemeal on an ongoing basis, I'm > looking for a way to include all such header files once and for all. >That's really going to hurt your compile time, btw... if you're interested in building a tool to help here, a tool that uses Clang to find and suggest headers to include (or to remove, to keep the include set minimal to avoid bloating compile time) would probably be good & I know there are some people working on such a thing. But it is more work, of course. (& may benefit from/need C++ modules support)> To that end, I wrote a Python script to generate include directives for > all .h files in llvm/include and its subdirectories. This almost works, but > getting two error messages: > > In file included from src\main.cpp:1: > In file included from src/../llvm.h:254: > In file included from > \llvm\include\llvm/DebugInfo/PDB/ConcreteSymbolEnumerator.h:13: > In file included from > \llvm\include\llvm/DebugInfo/PDB/IPDBEnumChildren.h:13: > \llvm\include\llvm/DebugInfo/PDB/PDBTypes.h(444,3) : error: redefinition > of enumerator 'Unknown' > Unknown, > ^ > \llvm\include\llvm/CodeGen/CallingConvLower.h(189,16) : note: previous > definition is here > typedef enum { Unknown, Prologue, Call } ParmContext; > ^ > In file included from src\main.cpp:1: > In file included from src/../llvm.h:298: > In file included from > \llvm\include\llvm/DebugInfo/PDB/DIA/DIADataStream.h:13: > \llvm\include\llvm/DebugInfo/PDB/DIA/DIASupport.h(30,10) : fatal error: > 'cvconst.h' file not found > #include <cvconst.h> > > Are there known fixes for these, or is there something I should be doing > differently? >The first one's probably an outright ODR violation (Zach - perhaps you could take a look at that) The second is probably because you're including a header that's only conditionally usable, when you have the right 3rd party package installed (at least I assume that's the case - Zach?) Did we actually install that header onto a system without the package available? Or are you pointing your build at an LLVM source tree? - Dave> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151209/18ff9911/attachment.html>
On Wed, Dec 9, 2015 at 3:58 PM, David Blaikie <dblaikie at gmail.com> wrote:> That's really going to hurt your compile time, btw... >Right, though compile time isn't a bottleneck for me; in any case, I've seen it said that that clang can do precompiled headers, so I was going to try that.> if you're interested in building a tool to help here, a tool that uses > Clang to find and suggest headers to include (or to remove, to keep the > include set minimal to avoid bloating compile time) would probably be good > & I know there are some people working on such a thing. But it is more > work, of course. (& may benefit from/need C++ modules support) >Yeah, there is an 'include what you need' tool. I tried it a month or two ago, and it didn't quite work, but came impressively close, closer than I expected. The second is probably because you're including a header that's only> conditionally usable, when you have the right 3rd party package installed > (at least I assume that's the case - Zach?) > > Did we actually install that header onto a system without the package > available? Or are you pointing your build at an LLVM source tree? >I'm on Windows, so package management doesn't apply; I'm using the 3.7.0 source tarball, so probably closer to the latter than the former. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151209/c581b2af/attachment.html>
On Wed, Dec 9, 2015 at 7:58 AM David Blaikie <dblaikie at gmail.com> wrote:> On Wed, Dec 9, 2015 at 7:11 AM, Russell Wallace via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Rather than including llvm header files piecemeal on an ongoing basis, >> I'm looking for a way to include all such header files once and for all. >> > > That's really going to hurt your compile time, btw... if you're interested > in building a tool to help here, a tool that uses Clang to find and suggest > headers to include (or to remove, to keep the include set minimal to avoid > bloating compile time) would probably be good & I know there are some > people working on such a thing. But it is more work, of course. (& may > benefit from/need C++ modules support) > > >> To that end, I wrote a Python script to generate include directives for >> all .h files in llvm/include and its subdirectories. This almost works, but >> getting two error messages: >> >> In file included from src\main.cpp:1: >> In file included from src/../llvm.h:254: >> In file included from >> \llvm\include\llvm/DebugInfo/PDB/ConcreteSymbolEnumerator.h:13: >> In file included from >> \llvm\include\llvm/DebugInfo/PDB/IPDBEnumChildren.h:13: >> \llvm\include\llvm/DebugInfo/PDB/PDBTypes.h(444,3) : error: redefinition >> of enumerator 'Unknown' >> Unknown, >> ^ >> \llvm\include\llvm/CodeGen/CallingConvLower.h(189,16) : note: previous >> definition is here >> typedef enum { Unknown, Prologue, Call } ParmContext; >> > Try changing PDB_VariantType to be enum class instead of enum. Everythingelse in that file is an enum class, it's possible this one just ended up as an enum by accident.> ^ >> In file included from src\main.cpp:1: >> In file included from src/../llvm.h:298: >> In file included from >> \llvm\include\llvm/DebugInfo/PDB/DIA/DIADataStream.h:13: >> \llvm\include\llvm/DebugInfo/PDB/DIA/DIASupport.h(30,10) : fatal error: >> 'cvconst.h' file not found >> #include <cvconst.h> >> >> Are there known fixes for these, or is there something I should be doing >> differently? >> > > The first one's probably an outright ODR violation (Zach - perhaps you > could take a look at that) > > The second is probably because you're including a header that's only > conditionally usable, when you have the right 3rd party package installed > (at least I assume that's the case - Zach?) > > Did we actually install that header onto a system without the package > available? Or are you pointing your build at an LLVM source tree? >I'm not sure how the source tarball works, but did you run CMake yourself or does the source tarball come with pre-generated CMake build files? It's only supposed to compile the DIA stuff if it finds DIA is installed on your machine at CMake gen time. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151209/41884a51/attachment.html>
Reasonably Related Threads
- Include all the things
- Gauging interest in generating PDBs from LLVM-backed languages
- Gauging interest in generating PDBs from LLVM-backed languages
- Gauging interest in generating PDBs from LLVM-backed languages
- Any objections to re-sorting #include lines with clang-format/clang-tidy?