Opened 3 years ago
Closed 3 years ago
#16385 closed defect (fixed)
llvm-14.0.0.src.tar.xz extracts to two directories
Reported by: | pierre | Owned by: | blfs-book |
---|---|---|---|
Priority: | low | Milestone: | 11.2 |
Component: | BOOK | Version: | git |
Severity: | normal | Keywords: | |
Cc: |
Description ¶
The tarball for llvm contains two directories:
$ tar tf /sources/llvm-14.0.0.src.tar.xz llvm-14.0.0.src/ [...] llvm-14.0.0.src/utils/yaml-bench/CMakeLists.txt llvm-14.0.0.src/utils/yaml-bench/YAMLBench.cpp cmake/ cmake/Modules/ cmake/Modules/EnableLanguageNolink.cmake [...]
I am not sure we want to do anything about that, but since it is an unusual behavior, I report it.
The main drawback is that it may get unnoticed, and not be removed after running the build.
Change History (6)
comment:1 by , 3 years ago
comment:2 by , 3 years ago
I guess upstream only builds the full project https://github.com/llvm/llvm-project/releases/download/llvmorg-14.0.0/llvm-project-14.0.0.src.tar.xz, which extracts to a unique directory.
comment:3 by , 3 years ago
Sigh. I tried:
rm -rf ./cmake
but the build failed with:
CMake Error at tools/clang/cmake/modules/CMakeLists.txt:1 (include): include could not find requested file: ExtendPath CMake Error at tools/clang/cmake/modules/CMakeLists.txt:3 (include): include could not find requested file: FindPrefixFromConfig CMake Error at tools/clang/cmake/modules/CMakeLists.txt:42 (find_prefix_from_config): Unknown CMake command "find_prefix_from_config".
In my case I build with:
DIR=$PWD rm -rf /build/llvm mkdir /build/llvm cd /build/llvm tar -xf $DIR/llvm-14.0.0.src.tar.xz
so the cmake gets deleted with /build/llvm each time I build it.
comment:4 by , 3 years ago
Upstream bug report link: https://github.com/llvm/llvm-project/issues/54716
comment:5 by , 3 years ago
Upstream seems not clear about what to do. What we have as instructions work presently. We just need to make users aware of the presence of the cmake
directory. I'd say we should just add a note. If usptream change their mind, we may have to change the instructions anyway. Then the note may or may not go away.
We could put a note. Or we could move it to some place inside the build directory, and sed some CMakeLists.txt (maybe not worth it, since there are 4 CMakeLists.txt files involved). Problem is that there is a variable for the location of this directory, but it is not cached, so it is redefined in each project that needs it... Stupid upstream, stupid cmake, again...