[cfe-dev] Where to put upcoming refcatoring tools

[Manuel Klimek]

On Tue, Apr 24, 2012 at 6:02 PM, Stephen Kelly <steveire at gmail.com> wrote:
> Stephen Kelly wrote:
>> Could you give me a llvm commit I'd be able to build against? Or a patch
>> to make it build again (I guess the extra needed arguments have to come
>> from somewhere)?
>>
>
> I commented out the conflicting code, and now I get this when trying to run
> the example:
>
> stephen at hal:~/dev/src/llvm{master}$ ~/dev/build/qt/llvm/bin/remove-cstr-
> calls ~/dev/build/qt/llvm/ ./unittests/VMCore/DominatorTreeTest.cpp
> Processing:
> /home/stephen/dev/src/llvm/unittests/VMCore/DominatorTreeTest.cpp.
> In file included from
> /home/stephen/dev/src/llvm/unittests/VMCore/DominatorTreeTest.cpp:1:
> In file included from
> /home/stephen/dev/src/llvm/include/llvm/Instructions.h:19:
> In file included from
> /home/stephen/dev/src/llvm/include/llvm/InstrTypes.h:19:
> In file included from
> /home/stephen/dev/src/llvm/include/llvm/Instruction.h:18:
> In file included from /home/stephen/dev/src/llvm/include/llvm/User.h:22:
> In file included from
> /home/stephen/dev/src/llvm/include/llvm/Support/ErrorHandling.h:19:
> In file included from
> /home/stephen/dev/src/llvm/include/llvm/ADT/StringRef.h:13:
> In file included from
> /home/stephen/dev/src/llvm/include/llvm/Support/type_traits.h:20:
> In file included from
> /home/stephen/dev/build/qt/llvm/include/llvm/Support/DataTypes.h:58:
> /usr/include/x86_64-linux-gnu/sys/types.h:147:10: fatal error: 'stddef.h'
> file not found
> #include <stddef.h>
>         ^
> 1 error generated.
> Error while processing
> /home/stephen/dev/src/llvm/unittests/VMCore/DominatorTreeTest.cpp.
>
> Is there more set-up I need to do?

Yes, but there shouldn't, so you just pointed me at a bug in the
tooling which I didn't notice because it's easily hidden behind a
clang system install :D

You can work around this for now by making sure that the compiler that
you configured as the compiler in the project where you created the
compile_commands.json (more specifically, the argv[0] in the "command"
entries in that file) is a clang installation where
basepath(argv[0])/../lib/clang/3.2/include  (or 3.1 depending on
whether you have a clang version pre-cut) exists.

The bug is that the tooling hands the full compile command line from
the compile_commands.json to the driver, which uses the argv[0] of
that to find its builtin includes. The fix is to replace this with the
current tool's argv[0] for the calls.

Cheers,
/Manuel