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>