Include all the things

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?

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

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.

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;

Sorry, perhaps a poor use of terms on my part - it still matters in the
sense that LLVM has external library dependencies you may need to have
installed, etc.

I'm using the 3.7.0 source tarball, so probably closer to the latter than
the former.

OK - yeah, not sure (perhaps Zach can help here, then) - you may need to
install some extra windows debug info development libraries so that header
is available to be included.

Try changing PDB_VariantType to be enum class instead of enum. Everything else in that file is an enum class, it’s possible this one just ended up as an enum by accident.

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.

I ran CMake myself.

Can you apply the following patch:

d:\src\llvm>git diff
diff --git a/lib/DebugInfo/PDB/CMakeLists.txt b/lib/DebugInfo/PDB/CMakeLists.txt
index 1645a95…7a5913c 100644
— a/lib/DebugInfo/PDB/CMakeLists.txt
+++ b/lib/DebugInfo/PDB/CMakeLists.txt
@@ -4,6 +4,7 @@ macro(add_pdb_impl_folder group)
endmacro()

if(HAVE_DIA_SDK)

  • message(“DIA SDK Dir = ${MSVC_DIA_SDK_DIR}”)
    include_directories(${MSVC_DIA_SDK_DIR}/include)
    set(LIBPDB_LINK_FOLDERS “${MSVC_DIA_SDK_DIR}\lib”)
    if (CMAKE_SIZEOF_VOID_P EQUAL 8)

then regenerate your CMake. Whatever directory prints out, browse to it in explorer and you should see include/cvconst.h. Is it possible you have a corrupt installation or something?

Ahh wait, this include is happening from your own project. Yea, you’ll need to manually add this folder to your include paths.