The LLVM source distribution includes CMake modules that make it easy to embed LLVM in an application. They are, however, not installed by the ebuild. Please add them. Reproducible: Always
Let me guess... they are installed by default when cmake is used to build llvm?
Yeah. It didn't occur to me to check the autotools build at all.
(In reply to comment #2) > Yeah. It didn't occur to me to check the autotools build at all. Hmm, I will sacrifice myself and try -9999 today. If it doesn't install them either, I will open a request at upstream to include them in future builds. In the meantime, I will add them to the current ebuilds. Do you need to depend on them in some ebuilds you'll be publishing? If no, I'll probably add them without a revision bump.
No, I'm just hacking on my own stuff. Is there any plan to move the ebuild to the CMake system? I could help with that, if it has a chance to get into the tree.
(In reply to comment #4) > Is there any plan to move the ebuild to the CMake system? I could help with > that, if it has a chance to get into the tree. I don't think that's worth doing with 3.1. I've looked into that already, and it seems that some of the options we're using aren't available in cmake. Could you point me which cmake modules should be installed?
These are the relevant files: * LLVMConfig.cmake * LLVMConfigVersion.cmake * LLVM-Config.cmake * AddLLVM.cmake * AddLLVMDefinitions.cmake * ChooseMSVCCRT.cmake * HandleLLVMOptions.cmake * LLVMParseArguments.cmake * LLVMProcessSources.cmake * TableGen.cmake The first two are processed from corresponding *.in files.
(In reply to comment #6) > These are the relevant files: > * LLVMConfig.cmake > * LLVMConfigVersion.cmake > * LLVM-Config.cmake > * AddLLVM.cmake > * AddLLVMDefinitions.cmake > * ChooseMSVCCRT.cmake > * HandleLLVMOptions.cmake > * LLVMParseArguments.cmake > * LLVMProcessSources.cmake > * TableGen.cmake > The first two are processed from corresponding *.in files. Ok, the processing is the problem. I've did a quick check and regular configure sed doesn't work on them...
I'll try to hack it into the autotools build (and ideally send it upstream), but I could do better with them, so it would probably take some time...
Is there any progress with this issue? I would like to package jllvm [http://code.google.com/p/jllvm/] because I will be using this software with my students. But jllvm building system nees LLVMConfig.cmake.
(In reply to comment #9) > Is there any progress with this issue? > > I would like to package jllvm [http://code.google.com/p/jllvm/] because I > will be using this software with my students. But jllvm building system nees > LLVMConfig.cmake. No, none that I am aware of. I haven't heard back from LLVM upstream nor Yaron.
@voyageur, shall I try building llvm+clang with cmake again? I think we could even accept losing a few minor features considering the general advantages.
Any updates to this bug? It's quite old by now. My interest lies mostly in the bug I've added as "Blocks".
I've just got this crazy idea... maybe we could be able to configure a source tree with both autoconf and cmake, with the former being used for the build and the latter to provide cmake modules. I will try to accomplish this.
Created attachment 365712 [details, diff] Proposed (untested yet) patch Here's my initial patch. It got really late, so I wouldn't be able to fully test it until tomorrow morning.
+ 20 Dec 2013; Michał Górny <mgorny@gentoo.org> llvm-9999.ebuild: + Fix gcc version check. Add missing libxml2 dependency (for clang). Install + CMake modules.
Created attachment 365750 [details, diff] Patch for 3.3-r1 Patch for llvm 3.3-r1.ebuild (it at least installed the cmake files, I haven't tried it yet) based on Michał Górny's changes to -9999.
*llvm-3.3-r2 (28 Dec 2013) 28 Dec 2013; Michał Górny <mgorny@gentoo.org> +files/llvm-3.3-r2-gentoo-install.patch, +llvm-3.3-r2.ebuild: Backport all the fixes and install design changes from -9999 to -3.3. Fixes bugs #425844 (install CMake modules), #462554 (install bfd-plugins symlink), #489586 (multilib portage compat.), #488216, #492554 (RPATH issues).
