Some files are not installed by both build systems, autoconf and cmake. eg. on x86_64-linux CentOS5, [autoconf] lacks on cmake bin/c-index-test docs/* include/clang/Config/config.h.cmake include/llvm/CMakeLists.txt include/llvm/Config/config.h.cmake include/llvm/Config/llvm-config.h.cmake include/llvm/Support/DataTypes.h.cmake include/llvm/Support/LICENSE.TXT lib/clang/2.9/include/nmmintrin.h lib/clang/2.9/include/varargs.h lib/clang/2.9/include/wmmintrin.h lib/clang/2.9/include/x86intrin.h lib/libclang.a lib/libCompilerDriver.a lib/libEnhancedDisassembly.so lib/libLTO.a lib/libLTO.so lib/libUnitTestMain.a lib/profile_rt.so share/man/man1/* [cmake] lacks on autoconf include/clang/Basic/*.td include/clang/Driver/*.td lib/libgtest.a lib/libgtest_main.a share/llvm/cmake/* I think they should be installed as below; include/llvm/Support/LICENSE.TXT lib/clang/2.9/include/*.h lib/libclang.a lib/libLTO.a lib/libLTO.so share/llvm/cmake/* Especially "clang standalone build with cmake" needs $(PREFIX)/share/llvm/cmake stuff.
On clang standalone build for "make clang-test", installed lit would be needed.
I have confirmed on linux, clang standalone build would be possible as long as $(PREFIX)/share/llvm/cmake.
(In reply to comment #0) > Some files are not installed by both build systems, autoconf and cmake. > > eg. on x86_64-linux CentOS5, > > [autoconf] lacks on cmake > bin/c-index-test This tool is used for testing clang, right? Can we test clang after it is installed? If not, are we interested on doing that? > docs/* Yep, there are TODOs the toplevel LLVM and Clang CMakeLists.txt file for that. > include/clang/Config/config.h.cmake > include/llvm/CMakeLists.txt > include/llvm/Config/config.h.cmake > include/llvm/Config/llvm-config.h.cmake > include/llvm/Support/DataTypes.h.cmake Those shouldn't be installed, as they are templates for generating other files. I filed PR2928 for that. > include/llvm/Support/LICENSE.TXT Aye. > lib/clang/2.9/include/nmmintrin.h > lib/clang/2.9/include/varargs
> Some files are not installed by both build systems, autoconf and cmake. > > eg. on x86_64-linux CentOS5, > > [autoconf] lacks on cmake > bin/c-index-test This tool is used for testing clang, right? Can we test clang after it is installed? If not, are we interested on doing that? > docs/* Yep, there are TODOs the toplevel LLVM and Clang CMakeLists.txt file for that. > include/clang/Config/config.h.cmake > include/llvm/CMakeLists.txt > include/llvm/Config/config.h.cmake > include/llvm/Config/llvm-config.h.cmake > include/llvm/Support/DataTypes.h.cmake Those shouldn't be installed, as they are templates for generating other files. I filed PR2928 for that. > include/llvm/Support/LICENSE.TXT Aye. > lib/clang/2.9/include/nmmintrin.h > lib/clang/2.9/include/varargs.h > lib/clang/2.9/include/wmmintrin.h > lib/clang/2.9/include/x86intrin.h Yes, we must update the list of files on lib/Headers/CMakeLists.txt. > lib/libclang.a We build and install libclang.so, so it is a matter of adding a new target for the static library. > lib/libCompilerDriver.a > lib/libEnhancedDisassembly.so > lib/libLTO.a > lib/libLTO.so > lib/libUnitTestMain.a > lib/profile_rt.so No idea about those. Where are their sources? (I could check myself if I weren't on a Windows netbook) Also, do we really need to install libUnitTestMain.a? > share/man/man1/* Same as Doc. > [cmake] lacks on autoconf > include/clang/Basic/*.td > include/clang/Driver/*.td The autoconf build shouldn't install those. > lib/libgtest.a > lib/libgtest_main.a It is necessary to install them? > share/llvm/cmake/* I don't think that it is realistic to expect from the autoconf build to properly install those files. > > I think they should be installed as below; > > include/llvm/Support/LICENSE.TXT > lib/clang/2.9/include/*.h > lib/libclang.a > lib/libLTO.a > lib/libLTO.so > share/llvm/cmake/* > > Especially "clang standalone build with cmake" needs $(PREFIX)/share/llvm/cmake > stuff. If you want to build Clang with cmake, you must build&install LLVM with cmake. Given the current user community we have, that's a reasonable requirement, IMHO.
(In reply to comment #4) > > I think they should be installed as below; > > > > include/llvm/Support/LICENSE.TXT > > lib/clang/2.9/include/*.h > > lib/libclang.a > > lib/libLTO.a > > lib/libLTO.so > > share/llvm/cmake/* > > > > Especially "clang standalone build with cmake" needs $(PREFIX)/share/llvm/cmake > > stuff. > > If you want to build Clang with cmake, you must build&install LLVM with cmake. > Given the current user community we have, that's a reasonable requirement, > IMHO. Let's think about coming binary releases! Would it be happier if a developer with clang would not need "llvm.tar.gz"? (though configuring LLVM.cmake and lit would be needed) Of course, I will work for these issues, too!
include/llvm/Support/LICENSE.TXT installed by r126571. lib/clang/2.9/include/nmmintrin.h lib/clang/2.9/include/varargs.h lib/clang/2.9/include/wmmintrin.h lib/clang/2.9/include/x86intrin.h installed by r126572. Still missing: bin/c-index-test docs/* lib/libclang.a lib/libCompilerDriver.a lib/libEnhancedDisassembly.so lib/libLTO.a lib/libLTO.so lib/libUnitTestMain.a lib/profile_rt.so share/man/man1/* We need to know if it is required to install libraries and utilities used by the testing framework (i.e. if we want to test an installed LLVM/Clang.)
> include/clang/Basic/*.td > include/clang/Driver/*.td It is not installed with r126633. (In reply to comment #6) > bin/c-index-test It is not installed with r126634. > lib/libUnitTestMain.a It is not installed with r126632. > lib/libgtest.a > lib/libgtest_main.a I have not tweaked them yet. > We need to know if it is required to install libraries and utilities used by > the testing framework (i.e. if we want to test an installed LLVM/Clang.) IMHO, we need "installed Lit". Detecting required tools would be nontrivial. :(
As of r127556 these files are installed: lib/libclang.a lib/libCompilerDriver.a lib/libEnhancedDisassembly.so lib/libLTO.a lib/libLTO.so Still missing: bin/c-index-test docs/* lib/libUnitTestMain.a lib/profile_rt.so share/man/man1/*
Thank you for working! Files installed by autoconf - bin/llvmc - docs/* - lib/profile_rt.so - share/man/man1/* Files installed by cmake - bin/clang-2.9 - lib/libclang.so.2.9 suffixless clang is installed on both. - bin/llvm-lit AFAIK, installed llvm-lit would be incomplete. It needs installing utils/lit, too. - include/clang/Config It is a directory and harmless. - lib/libgtest.a - lib/libgtest_main.a They may be suppressed. - share/llvm/cmake/* I will implement on autoconf in future. (as you might know, I am very busy...) (In reply to comment #8) > Still missing: > > bin/c-index-test It has not been installed since r126634. > lib/libUnitTestMain.a It has not been installed since r126632.
(In reply to comment #8) > As of r127556 these files are installed: > > lib/libclang.a > lib/libCompilerDriver.a > lib/libEnhancedDisassembly.so > lib/libLTO.a > lib/libLTO.so > > Still missing: > > bin/c-index-test > docs/* > lib/libUnitTestMain.a > lib/profile_rt.so > share/man/man1/* It is great if the FileCheck util also install, so out of tree build projects can use it for regression test.
(In reply to comment #10) > It is great if the FileCheck util also install, so out of tree build projects > can use it for regression test. When I try building and testing standalone clang with LLVM binary distribution made by "make install", a few utils/* are missing. Lit should be installed by python installer, Daniel said (and I did). LLVM may provide testing utilities, IMO. LLVM is "the infrastructure".
*** Bug 13333 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > - share/llvm/cmake/* > I will implement on autoconf in future. > (as you might know, I am very busy...) Gentoo users would appreciate very much. We are using autoconf to build llvm, and packages which have only cmake-based build system expect those modules.
(In reply to comment #9) > - share/llvm/cmake/* > I will implement on autoconf in future. > (as you might know, I am very busy...) > Takumi, are you still working on this? I am a Gentoo user and I need these cmake files. If you are too busy, I don’t mind tweaking the autoconf myself, but I need to be unblocked on this and I wouldn’t want our works to overlap :) Cheers
Created attachment 10676 [details] Adds a Makefile that installs files from cmake/modules
Okay, I assume that Takumi is very busy since he hasn’t answered for almost a year. I had a look at the bug and I will comment on it because at the time of writing I am a bit stuck. The mentioned files are not installed simply because no Makefile is present to install them. The obvious solution is to create the missing Makefile in cmake/modules, and tweak the root-level Makefile so that it also calls the cmake/modules Makefile. I attached a patch that does that, however, this is not sufficient. Some of the files cannot be installed because they need to be generated by autoconf: LLVMConfig.cmake.in → LLVMConfig.cmake LLVMConfigVersion.cmake.in → LLVMConfigVersion.cmake My problem now is that running autoconf just doesn’t work on my computer. I suspect the version is too outdated to be working. According to autoconf/AutoRegen.sh, the project relies on autoconf-2.60 (which was released 7 years ago), and I use 2.68. So the next logical step would be to update autoconf. Also, I am a bit confused as where to install these scripts. On my OS, I believe they should be placed in /usr/share/cmake/Modules, but people in this thread have been indicating other locations. If anyone could shed some lights on that, that would be great. So this is the first step of a solution, any help is appreciated.
As far as autoconf, instead of upgrading the version that llvm uses to 2.68, how about just installing 2.60 from ftp.gnu.org in a temporary directory? This is how I do it.
(In reply to comment #17) > As far as autoconf, instead of upgrading the version that llvm uses to 2.68, > how about just installing 2.60 from ftp.gnu.org in a temporary directory? > This is how I do it. Nice! thanks for the workaround, I didn’t think of that. I still think it is preferable to upgrade autoconf, even though it is a bit more work, unless llvm maintainers are willing to drop support altogether (but I doubt it because this discussion thread seems to indicate otherwise http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-May/062459.html). As this bug is the counterpart of another bug on Gentoo (https://bugs.gentoo.org/show_bug.cgi?id=425844), your workaround could be a solution there too, even though I suspect it will be frown upon.
Yes, I was the one that proposed it this last time. It's a much longer process so you definitely shouldn't depend upon it. That said, upgrading the autoconf version is ok with me, though not necessary and the gentoo people shouldn't need to run autoconf so I can't see how it would help there?
(In reply to comment #19) > That said, upgrading the autoconf version is ok with me, though not > necessary and the gentoo people shouldn't need to run autoconf so I can't > see how it would help there? I am not sure I understand what you mean by "the gentoo people shouldn't need to run autoconf". Michał pointed out that we are already using autoconf (comment #13), and some files are not generated by the present ./configure (comment #16), which means that we need to run autoconf if we want these files installed. Unless you mean that we could rely on a cmake-based build? In the meantime, I have started working on a patch to upgrade the autoconf build system and made some progress there. Would you mind opening a new bug so we can keep track of that? Cheers
Created attachment 10710 [details] llvm-3.3-autoconf-install-cmake-scripts.patch This patch fixes the issue of cmake scripts not being installed by autoconf in llvm-3.3 (needs some testing!)
(In reply to comment #21) > Created attachment 10710 [details] > llvm-3.3-autoconf-install-cmake-scripts.patch > > This patch fixes the issue of cmake scripts not being installed by autoconf > in llvm-3.3 (needs some testing!) Does this do proper substitutions? I'd appreciate if you could run a cmake and autotools build side-by-side and compare the files.
Created attachment 10762 [details] llvm-3.3-autoconf-install-cmake-scripts.patch (In reply to comment #22) I compared 2 different installations (cmake, and autoconf patched with #10710) as you suggested, and found some differences. So I modified the patch to fix them. Here is an updated version of the patch. I have used the versions of autoconf, automake and libtool which fit the requirements expressed in AutoRegen.sh (i.e. autoconf 2.60, automake 1.9.6, libtool 1.5.22). Once installed, I compared the 2 directories: diff -rq patched-autoconf-prefix/ cmake-prefix/ | grep -v differ Only in cmake-prefix/bin: llvm-lit Only in patched-autoconf-prefix/: docs Only in cmake-prefix/lib: libgtest.a Only in cmake-prefix/lib: libgtest_main.a So this newer version is still incomplete as llvm-lit is not installed, but it does install the cmake scripts. I am working on that problem right now.
Created attachment 10765 [details] llvm-3.3-autoconf-install-missing-files.patch This patch installs llvm-lit as well as the missing scripts from cmake/modules. After applying the patch, installing and comparing the files installed from the autoconf build and the cmake build, the differences are: diff -qr cmake-prefix/ patched-autoconf-prefix/ | grep -v differ$ Only in patched-autoconf-prefix/: docs Only in cmake-prefix/lib: libgtest.a Only in cmake-prefix/lib: libgtest_main.a I believe this should be good now. Anyone could confirm?
(In reply to comment #16) > Some of the files cannot be installed because they need to be generated by autoconf: > > LLVMConfig.cmake.in → LLVMConfig.cmake > LLVMConfigVersion.cmake.in → LLVMConfigVersion.cmake I've posted a patch series to llvm-commits that teaches the Makefile-based (autotools) build system to provide these files: Improving support for CMake-based applications http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/173517 The series also improves the files generated both by Makefile and by CMake builds to provide the LLVM libraries as CMake imported targets to that application code can use them by name and get dependencies hooked up properly.
Since all of Brad's patches were applied, Resolved/Fixed?
(In reply to comment #26) > Since all of Brad's patches were applied, Resolved/Fixed? I think the bug is more general than that. Specifically, there are two dependant bugs still open.