Closed GoogleCodeExporter closed 9 years ago
What does the following say:
$ find /usr/lib -name "*clang*"
$ find /usr/lib -name "*LLVM*"
?
Original comment by kim.gras...@gmail.com
on 8 Feb 2015 at 6:44
$ find /usr/lib -name "*clang*"
/usr/lib/clang
/usr/lib/clang/3.5.0/lib/linux/libclang_rt.asan-x86_64.a
/usr/lib/clang/3.5.0/lib/linux/libclang_rt.asan_cxx-x86_64.a
/usr/lib/clang/3.5.0/lib/linux/libclang_rt.builtins-x86_64.a
/usr/lib/clang/3.5.0/lib/linux/libclang_rt.dfsan-x86_64.a
/usr/lib/clang/3.5.0/lib/linux/libclang_rt.lsan-x86_64.a
/usr/lib/clang/3.5.0/lib/linux/libclang_rt.msan-x86_64.a
/usr/lib/clang/3.5.0/lib/linux/libclang_rt.profile-x86_64.a
/usr/lib/clang/3.5.0/lib/linux/libclang_rt.san-x86_64.a
/usr/lib/clang/3.5.0/lib/linux/libclang_rt.tsan-x86_64.a
/usr/lib/clang/3.5.0/lib/linux/libclang_rt.ubsan-x86_64.a
/usr/lib/clang/3.5.0/lib/linux/libclang_rt.ubsan_cxx-x86_64.a
$ find /usr/lib -name "*LLVM*"
Original comment by pho...@gmail.com
on 8 Feb 2015 at 6:46
There is these too though:
$ find /usr/lib64 -name "*clang*"
/usr/lib64/llvm/libclang.so
/usr/lib64/llvm/libclang.a
/usr/lib64/llvm/libclangARCMigrate.a
/usr/lib64/llvm/libclangAST.a
/usr/lib64/llvm/libclangASTMatchers.a
/usr/lib64/llvm/libclangAnalysis.a
/usr/lib64/llvm/libclangBasic.a
/usr/lib64/llvm/libclangCodeGen.a
/usr/lib64/llvm/libclangDriver.a
/usr/lib64/llvm/libclangDynamicASTMatchers.a
/usr/lib64/llvm/libclangEdit.a
/usr/lib64/llvm/libclangFormat.a
/usr/lib64/llvm/libclangFrontend.a
/usr/lib64/llvm/libclangFrontendTool.a
/usr/lib64/llvm/libclangIndex.a
/usr/lib64/llvm/libclangLex.a
/usr/lib64/llvm/libclangParse.a
/usr/lib64/llvm/libclangRewrite.a
/usr/lib64/llvm/libclangRewriteFrontend.a
/usr/lib64/llvm/libclangSema.a
/usr/lib64/llvm/libclangSerialization.a
/usr/lib64/llvm/libclangStaticAnalyzerCheckers.a
/usr/lib64/llvm/libclangStaticAnalyzerCore.a
/usr/lib64/llvm/libclangStaticAnalyzerFrontend.a
/usr/lib64/llvm/libclangTooling.a
$ find /usr/lib64 -name "*llvm*"
/usr/lib64/llvm
/usr/lib64/llvm/libllvm.a
/usr/lib64/llvm/libllvm_AArch64.a
/usr/lib64/llvm/libllvm_ARM.a
/usr/lib64/llvm/libllvm_CppBackend.a
/usr/lib64/llvm/libllvm_NVPTX.a
/usr/lib64/llvm/libllvm_PowerPC.a
/usr/lib64/llvm/libllvm_R600.a
/usr/lib64/llvm/libllvm_SystemZ.a
/usr/lib64/llvm/libllvm_X86.a
/usr/lib64/llvm/libllvm_all_backends.a
/usr/lib64/llvm/libllvm_analysis.a
/usr/lib64/llvm/libllvm_bitreader.a
/usr/lib64/llvm/libllvm_bitwriter.a
/usr/lib64/llvm/libllvm_executionengine.a
/usr/lib64/llvm/libllvm_ipo.a
/usr/lib64/llvm/libllvm_irreader.a
/usr/lib64/llvm/libllvm_linker.a
/usr/lib64/llvm/libllvm_passmgr_builder.a
/usr/lib64/llvm/libllvm_scalar_opts.a
/usr/lib64/llvm/libllvm_target.a
/usr/lib64/llvm/libllvm_vectorize.a
Original comment by pho...@gmail.com
on 8 Feb 2015 at 6:47
Oh, I missed your `/usr/lib64/llvm` in the CMake command-line.
IWYU's CMakeLists.txt uses the LLVM_PATH as a base for both lib and include
dirs:
link_directories(${LLVM_PATH}/lib)
include_directories(${LLVM_PATH}/include)
and I don't see how to reconcile that with the way your libraries are
installed...
You'll probably have to patch CMakeLists locally to let the IWYU build find
your libs.
The only way I can see to make IWYU handle a case like this is to take CMake
args for both lib and include path (assuming your clang/LLVM headers are in
/usr/include somewhere), maybe that's something we need to consider...
Original comment by kim.gras...@gmail.com
on 8 Feb 2015 at 7:02
Thanks. I will try patching CMakeList.
This is standard fedora. The headers are under /usr/include/llvm and
/usr/include/clang, A separate option for lib and include would be helpful
indeed.
Original comment by pho...@gmail.com
on 8 Feb 2015 at 7:10
See if this patch helps.
I've added two branches for out-of-tree builds:
- You can pass -DIWYU_LLVM_ROOT_PATH=<install root> to point to a directory
where all LLVM and Clang's headers and libs are in a single tree
- You can pass -DIWYU_LLVM_INCLUDE_PATH= _and_ -DIWYU_LLVM_LIB_PATH= to point
at two different directories, one for libraries and one for headers
The last one matches your environment.
Let me know if this looks good to commit.
Original comment by kim.gras...@gmail.com
on 9 Feb 2015 at 8:51
Attachments:
Yep, with that patch it builds here using:
cmake -G "Unix Makefiles"
-DIWYU_LLVM_INCLUDE_PATH=/usr/include/clang/ClangFrontend
-DIWYU_LLVM_LIB_PATH=/usr/lib64/llvm
Thanks!
Original comment by pho...@gmail.com
on 9 Feb 2015 at 9:57
On a semi-related note, I'm working on getting include-what-you-use packaged
for Fedora and RHEL/EPEL. It's close to being completed/approved (
https://bugzilla.redhat.com/show_bug.cgi?id=1091659 ) and then you should be
able to use it without building it yourself.
Original comment by davejohansen
on 9 Feb 2015 at 10:31
Glad to hear it works, but...
> cmake -G "Unix Makefiles"
-DIWYU_LLVM_INCLUDE_PATH=/usr/include/clang/ClangFrontend
-DIWYU_LLVM_LIB_PATH=/usr/lib64/llvm
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
... the include path looks completely crazy :-) I would've expected just
/usr/include here.
Original comment by kim.gras...@gmail.com
on 10 Feb 2015 at 4:48
Yes :) I was going by trial and error. As thought /usr/include failed so I
tried with /usr/include/llvm, /usr/include/clang, and finally
/usr/include/clang/ClangFrontend because that was what it was complaining about
first.
Now that I try again with just /usr/include it works. Strange but good :)
Original comment by pho...@gmail.com
on 10 Feb 2015 at 7:54
OK, that makes more sense :-)
It could be that the include path is superfluous here, because /usr/include
should already be on your include path. So the /usr/include/clang/ClangFrontend
may just have been ignored.
I'll wait for review comments before committing; thanks for reporting and
helping verify!
Original comment by kim.gras...@gmail.com
on 10 Feb 2015 at 8:50
Overall the patch looks good to me. Good job, Kim. You've changed LLVM_PATH to
IWYU_LLVM_ROOT_PATH to be consistent with other options, right? Because it
inconveniences users who are using LLVM_PATH, especially in scripts. What about
keeping LLVM_PATH for backward compatibility, but don't mention it in error
message?
And it's not entirely clear when to use each option. But I doubt it can be
explained in CMakeLists.txt, the better place is wiki.
Original comment by vsap...@gmail.com
on 16 Feb 2015 at 2:38
Thanks for review!
Yes, the renaming of LLVM_PATH was for consistency and for making it clear that
it's an IWYU option, not an LLVM option. I'd like for people to move away from
LLVM_PATH for that reason. What if I add a deprecation warning about LLVM_PATH
and we drop it later?
Updating the wiki didn't occur to me, so thanks for the reminder, I'll do that
as soon as this gets in.
Original comment by kim.gras...@gmail.com
on 16 Feb 2015 at 5:50
Here's an updated patch:
- Add deprecation warning for LLVM_PATH (now called IWYU_LLVM_ROOT_PATH)
- Translate IWYU_LLVM_ROOT_PATH to IWYU_LLVM_INCLUDE_PATH and
IWYU_LLVM_LIB_PATH so they're always set
- Nicer formatting
Original comment by kim.gras...@gmail.com
on 18 Feb 2015 at 8:23
Attachments:
Looks good to me, feel free to commit the change.
And for the future, I think we can remove LLVM_PATH after one full release
cycle. I.e. after IWYU 0.5 (Clang 3.7) is released.
Original comment by vsap...@gmail.com
on 23 Feb 2015 at 4:56
Yes, that was my plan to remove LLVM_PATH.
Thanks, r602.
Original comment by kim.gras...@gmail.com
on 23 Feb 2015 at 6:21
OK, I'm closing this.
Original comment by kim.gras...@gmail.com
on 2 Mar 2015 at 8:42
Original issue reported on code.google.com by
pho...@gmail.com
on 8 Feb 2015 at 1:59