This is an archive of the discontinued LLVM Phabricator instance.

Move googletest to the third-party directory
ClosedPublic

Authored by tstellar on Aug 15 2022, 1:40 PM.

Details

Summary

This will help improve the project's layering, so that sub-projects
that don't actually need any llvm code can still use googletest
without having to reference code in the llvm directory.

This will also make it easier to consolidate and simplify the standalone
build configurations.

Diff Detail

Event Timeline

tstellar created this revision.Aug 15 2022, 1:40 PM
Herald added a project: Restricted Project. · View Herald Transcript
tstellar requested review of this revision.Aug 15 2022, 1:40 PM
Herald added projects: Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptAug 15 2022, 1:40 PM
Herald added subscribers: lldb-commits, Restricted Project, cfe-commits and 2 others. · View Herald Transcript
lattner accepted this revision.Aug 15 2022, 1:42 PM

I didn't review the patch in detail, but +1 this is a great step forward to reorganize the repo!

This revision is now accepted and ready to land.Aug 15 2022, 1:42 PM
phosek accepted this revision.Aug 15 2022, 1:47 PM

LGTM

llvm/cmake/modules/HandleLLVMOptions.cmake
1264

Is the implication that this file should only ever be included by top-level sub-projects (i.e. clang, mlir, llvm, etc)? If included from elsewhere, it seems like it won't do the right thing.

Also, having this as a cache entry is going to make it harder for out of tree projects to define it reliably (requiring various FORCE heroics) -- but I know why you are doing it if trying to define it here.

As is, this file is included from most of the top-levels and making it a cache variable will have them racing to set it. Why not make it a regular variable? And why not derive it from LLVM_MAIN_SRC_DIR?

tstellar added inline comments.Aug 15 2022, 4:37 PM
llvm/cmake/modules/HandleLLVMOptions.cmake
1264

I put it in this file so that this variable would be available for stand-alone builds and made it a cache variable so it could be overridden by standalone builds too.

The alternative would be to define this variable in llvm/CMakeLists.txt and then in the stand-alone build handling for each sub-project. It's a lot of code duplication that way, but we already have a lot of similar duplication in the CMakeLists.txt today (this is something I would like to clean up in the future).

Using LLVM_MAIN_SRC_DIR here breaks stand-alone builds, because LLVM_MAIN_SRC_DIR expands to ../llvm/../, so if I try to build lld, with a directory layout of:

lld/ cmake/ third-party/

Then CMake won't be able to find the third-party/ directory even though it is in the right place (because llvm/ is missing). I also think in general, it's cleaner to only use LLVM_MAIN_SRC_DIR when we want to use files in llvm/ and not for finding the root of the monorepo.

stellaraccident accepted this revision.Aug 15 2022, 9:16 PM
stellaraccident added inline comments.
llvm/cmake/modules/HandleLLVMOptions.cmake
1264

Thanks - I think I understand why you are doing it this way. I'm just trying to think of a way that has fewer thorns... And not being successful (without major surgery on the way this cmake setup is layered). I'm fine with how you have it.

probinson added inline comments.Aug 25 2022, 10:39 AM
clang/CMakeLists.txt
118

Should this be third-party/unittest ? Looking at how the lldb cmake files were modified.

lld/CMakeLists.txt
75

See comment for clang/CMakeLists.txt

mlir/CMakeLists.txt
30

See comment for clang/CMakeLists.txt

polly/CMakeLists.txt
34

See comment for clang/CMakeLists.txt

Semi-OT: polly\lib\External has 3 more third-party libraries. Two of them have been heavily modified in-tree, the third has just a custom CMakeLists.txt.
Should these eventually also be moved?

Semi-OT: polly\lib\External has 3 more third-party libraries. Two of them have been heavily modified in-tree, the third has just a custom CMakeLists.txt.
Should these eventually also be moved?

I don't know that there's a formal policy. Our copy of googletest is used by several projects, so unhooking it from the llvm tree has value in that regard.
Heavy modification might not be a blocker; googletest is somewhat stripped-down, although otherwise I think only lightly modified.

tstellar updated this revision to Diff 468784.Oct 18 2022, 10:27 PM
tstellar marked 4 inline comments as done.

Rebase and fix some missed path updates.

@probinson Does this latest update look better?

probinson accepted this revision.Nov 3 2022, 5:54 PM

Yes, LGTM

This revision was landed with ongoing or failed builds.Nov 9 2022, 11:10 AM
This revision was automatically updated to reflect the committed changes.