Extracted from D99484. My new plan is to start from the outside and work
inward.
Details
Details
- Reviewers
compnerd phosek MaskRay stephenneuendorffer - Group Reviewers
Restricted Project - Commits
- rG896537048df7: [lld][CMake] Use `GNUInstallDirs` to support custom installation dirs
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
- Updating D115568: [lld] Use GNUInstallDirs to support custom installation dirs. #
- Enter a brief description of the changes included in this update.
- The first line is used as subject, next lines as comment. #
- If you intended to create a new revision, use:
- $ arc diff --create
Fix typo
Comment Actions
- Updating D115568: [lld] Use GNUInstallDirs to support custom installation dirs. #
- Enter a brief description of the changes included in this update.
- The first line is used as subject, next lines as comment. #
- If you intended to create a new revision, use:
- $ arc diff --create
fix typo and simplify
| lld/cmake/modules/CMakeLists.txt | ||
|---|---|---|
| 29–39 ↗ | (On Diff #394115) | Could we move this to a top-level CMake module in https://github.com/llvm/llvm-project/tree/main/cmake/Modules so we can avoid duplicating this logic in every subproject? |
| lld/cmake/modules/CMakeLists.txt | ||
|---|---|---|
| 29–39 ↗ | (On Diff #394115) | Oh I didn't realize there was such a top-level dir, great! |
Comment Actions
- Updating D115568: [lld] Use GNUInstallDirs to support custom installation dirs. #
- Enter a brief description of the changes included in this update.
- The first line is used as subject, next lines as comment. #
- If you intended to create a new revision, use:
- $ arc diff --create
factor out functions
| lld/cmake/modules/CMakeLists.txt | ||
|---|---|---|
| 29–39 ↗ | (On Diff #394115) | This is now done, and I rebased it atop D115746 which does something similar. (we removed similar project-wide prefix variables in libc++, libc++abi, and libc++ before, but I suppose now that we have this function, if someone were to chime in that they wanted them back after all, it wouldn't be such a nuisance to support.) |
Comment Actions
- Updating D115568: [lld] Use GNUInstallDirs to support custom installation dirs. #
- Enter a brief description of the changes included in this update.
- The first line is used as subject, next lines as comment. #
- If you intended to create a new revision, use:
- $ arc diff --create
rebase on arc diff of the other
Comment Actions
- Updating D115568: [lld][cmake] Use GNUInstallDirs to support custom installation dirs. #
- Enter a brief description of the changes included in this update.
- The first line is used as subject, next lines as comment. #
- If you intended to create a new revision, use:
- $ arc diff --create
Rebase to hopefully fix pre-merge CI
Comment Actions
- Updating D115568: [lld][cmake] Use GNUInstallDirs to support custom installation dirs. #
- Enter a brief description of the changes included in this update.
- The first line is used as subject, next lines as comment. #
- If you intended to create a new revision, use:
- $ arc diff --create
Fix mod inc path
Comment Actions
- Updating D115568: [lld][cmake] Use GNUInstallDirs to support custom installation dirs. #
- Enter a brief description of the changes included in this update.
- The first line is used as subject, next lines as comment. #
- If you intended to create a new revision, use:
- $ arc diff --create
rebase
Comment Actions
- Updating D115568: [lld] Use GNUInstallDirs to support custom installation dirs. #
- Enter a brief description of the changes included in this update.
- The first line is used as subject, next lines as comment. #
- If you intended to create a new revision, use:
- $ arc diff --create
fix base cmake import
| lld/CMakeLists.txt | ||
|---|---|---|
| 163 | This broke building in my setups. In my setups, I still symlink the clang/lld directories into llvm/tools instead of invoking them via LLVM_ENABLE_PROJECTS. Thus referring to ${LLD_SOURCE_DIR}/.. ends up at llvm-project/llvm/tools instead of at llvm-project. Is there some better cmake variable we could use here for unambiguously referring to the monorepo root? (As backstory - a condition for me for getting away from building in that legacy setup, would be to be able to build things with the main llvm-project directory as main target directory for the cmake invocation. When pointing cmake at llvm-project/llvm, cmake uses relative paths for all files under the llvm subdir, but uses absolute paths for files under e.g. llvm-project/lld. With those tools symlinked under llvm-project/llvm/tools, it ends up using relative paths for all files. Using relative paths for compiling files is vital for being able to use ccache across different source trees, otherwise all built object files are unique for each source tree, due to e.g. paths in assert messages.) | |
| lld/CMakeLists.txt | ||
|---|---|---|
| 163 | I guess a working, but inelegant, solution would be to use ${LLVM_MAIN_SRC_DIR}/../cmake if it happens to exist, otherwise fall back on ${LLD_SOURCE_DIR}/../cmake. The former would normally work, but could maybe fail if building lld standalone without being invoked from the main llvm tree, and the llvm-project source tree has been moved since llvm itself was built. | |
| lld/CMakeLists.txt | ||
|---|---|---|
| 163 | Sorry about this. The runtime libraries (compile-rt, libunwind, libcxxabi, etc.) do this already, so I figured it was OK. As a temp hack, you can symlink the repo-root cmake as llvm/tools/cmake. That should fix the ../cmake, right? I think the better thing to do is simply make a new CACHE PATH for "shared cmake utils" in each of these projects, so you can set that one however you like. | |
This broke building in my setups.
In my setups, I still symlink the clang/lld directories into llvm/tools instead of invoking them via LLVM_ENABLE_PROJECTS. Thus referring to ${LLD_SOURCE_DIR}/.. ends up at llvm-project/llvm/tools instead of at llvm-project.
Is there some better cmake variable we could use here for unambiguously referring to the monorepo root?
(As backstory - a condition for me for getting away from building in that legacy setup, would be to be able to build things with the main llvm-project directory as main target directory for the cmake invocation. When pointing cmake at llvm-project/llvm, cmake uses relative paths for all files under the llvm subdir, but uses absolute paths for files under e.g. llvm-project/lld. With those tools symlinked under llvm-project/llvm/tools, it ends up using relative paths for all files. Using relative paths for compiling files is vital for being able to use ccache across different source trees, otherwise all built object files are unique for each source tree, due to e.g. paths in assert messages.)