This is an archive of the discontinued LLVM Phabricator instance.

[CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working.
ClosedPublic

Authored by beanz on Jun 23 2015, 10:59 AM.

Details

Summary

The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are:

  • factored out canonicalizing tool names from paths to CMake variables
  • removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools
  • removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off
  • Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code.
  • Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt

Diff Detail

Event Timeline

beanz updated this revision to Diff 28264.Jun 23 2015, 10:59 AM
beanz retitled this revision from to [CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working..
beanz updated this object.
beanz edited the test plan for this revision. (Show Details)
beanz added reviewers: bogner, samsonov, chapuni.
beanz added a subscriber: Unknown Object (MLST).
beanz accepted this revision.Jul 7 2015, 1:22 PM
beanz added a reviewer: beanz.

Marking as approved as per Bogner's reply on llvm-commits from 6/25.

This revision is now accepted and ready to land.Jul 7 2015, 1:22 PM
This revision was automatically updated to reflect the committed changes.
wjywbs added a subscriber: wjywbs.Jul 23 2015, 7:46 PM

I'm not exactly sure but I think this commit broke cmake when extra, llgo, lld and lldb are not checked out. Could you please check the following error log?

CMake Error at cmake/modules/AddLLVM.cmake:710 (add_subdirectory):
  add_subdirectory given source
  "/path/to/llvm/tools/clang/tools/extra" which is not an
  existing directory.
Call Stack (most recent call first):
  tools/clang/tools/CMakeLists.txt:24 (add_llvm_external_project)


CMake Error at cmake/modules/AddLLVM.cmake:710 (add_subdirectory):
  add_subdirectory given source
  "/path/to/llvm/tools/llgo" which is not an existing
  directory.
Call Stack (most recent call first):
  tools/CMakeLists.txt:36 (add_llvm_external_project)


CMake Error at cmake/modules/AddLLVM.cmake:710 (add_subdirectory):
  add_subdirectory given source "/path/to/llvm/tools/lld"
  which is not an existing directory.
Call Stack (most recent call first):
  tools/CMakeLists.txt:37 (add_llvm_external_project)


CMake Error at cmake/modules/AddLLVM.cmake:710 (add_subdirectory):
  add_subdirectory given source
  "/path/to/llvm/tools/lldb" which is not an existing
  directory.
Call Stack (most recent call first):
  tools/CMakeLists.txt:38 (add_llvm_external_project)
beanz added a subscriber: beanz.Jul 23 2015, 10:24 PM

Delete the CMakeCache.txt file from your build directory.

-Chris

Thanks Chris! It worked.

chapuni edited edge metadata.Jul 24 2015, 4:48 PM

This makes harder for walking revisions before r242059.
I think it'd be really bad idea to require removing CMakeCache.txt.

Chris, could you consider how to satisfy build tree before r242059?

beanz added a comment.Jul 24 2015, 6:03 PM

CMake has no mechanism for cache invalidation. Unless we all start writing perfect forward-looking code the first time, every time we're going to have to accept that sometimes the CMakeCache will need to be deleted if you go backwards or forwards by large increments.

In this case, when I first found the caching issue I landed a patch to cleanup the caches on builders and developer machines so that everyone didn't need to delete their caches. I think that is the best we can expect. I don't think it is reasonable to expect that you'll never have to delete your CMakeCache or even the whole build directory.

There should be no problem walking back in revisions with my patch, but walking forward if you jump over the patch that I landed to clear out the cache (which sat in tree for a few days) you will need to delete your cache. Re-generating the cache is quite fast, and some of our bots (specifically the Jenkins ones) even do it on every build.

-Chris