[PATCH] D73253: [llvm] Fix file ignoring inside directories

Martin Storsjö via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 23 23:01:32 PST 2020


mstorsjo added a comment.

In D73253#1837218 <https://reviews.llvm.org/D73253#1837218>, @smeenai wrote:

> In D73253#1836910 <https://reviews.llvm.org/D73253#1836910>, @jyknight wrote:
>
> > I think we should instead remove the entire "tracked independently" parts, because that's no longer the recommended directory layout. And also remove these "global" ignores which you moved, because they're already in /.gitignore, and thus don't need to be in /llvm/.gitignore
>
>
> I'm good doing so, although I'll note that we haven't officially removed support for the nested layout yet (although I can't imagine why someone would want to use the nested layout with the monorepo).


I still use the nested layout with the monorepo, due to interactions between cmake and ccache. For source files below the directory of the main toplevel cmake file (llvm-project/llvm), cmake will use relative paths if the build dir also is under the same directory (llvm-project/llvm/build). But for source files outside of that (llvm-project/clang), cmake will generate absolute paths.

In an asserts build, the pathname used to refer to a file ends up embedded in the built object files a lot (in each assert message). If the pathname is absolute, ccache is unable to share the built object files between two build trees on the same machine, and I quite intentionally use multiple build trees for being able to pre-build newer versions to populate ccache. In my setup, with the hw I have available for developing llvm, this is cruicial for not having to synchronously stop the main work for 1h+ every time I'd like to update to a newer master version.

If it's possible to build using a toplevel CMakeLists.txt directly in the llvm-project root, instead of in the llvm subdir, the proper monorepo build procedure would work fine for me. I brought this up on llvm-dev earlier, and @beanz said it would be doable but requires a bit of additional work: http://lists.llvm.org/pipermail/llvm-dev/2019-November/136466.html

So I'd prefer being able to symlink things into llvm/tools until this is resolved.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73253/new/

https://reviews.llvm.org/D73253





More information about the llvm-commits mailing list