[llvm-dev] Include all the things

[Zachary Turner via llvm-dev]

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.  Everything
else 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>