This is an archive of the discontinued LLVM Phabricator instance.

CMakeLists: Don't set LLVM_MAIN_SRC_DIR when building stand-alone clang
Needs RevisionPublic

Authored by tstellar on Apr 27 2017, 9:08 AM.

Details

Summary

clang was using LLVM_MAIN_SRC_DIR to search for lit.py to use for
running clang's lit tests. This was dangerous though, because
LLVM_MAIN_SRC_DIR was determined by using llvm-config --src-root
and this directory may have been modified since llvm-config was
built (e.g. User builds and install llvm trunk and then checks out the
release_40 branch in their source tree).

Event Timeline

tstellar created this revision.Apr 27 2017, 9:08 AM
chapuni edited edge metadata.Apr 27 2017, 4:11 PM

Let me know steps for testing that you suppose.
I guess;

  • Use installed version of lit via virtualenv.
  • Use out-of-tree version of gtest.
  • Use another build tree to use FileCheck &c.

I know the clause CLANG_BUILT_STANDALONE would be made simpler if we could abandon testing in standalone build.

Let me know steps for testing that you suppose.
I guess;

  • Use installed version of lit via virtualenv.

Not necessarily via virtualenv, either by installing the lit pypi package or using a distro package: https://admin.fedoraproject.org/pkgdb/package/rpms/python-lit/

  • Use out-of-tree version of gtest.

I don't really have a plan for gtest, but this already doesn't work for out of tree builds (unless you have the source tree on your system, but I don't think we should be relying on this).

  • Use another build tree to use FileCheck &c.

These could come from a build tree or could be installed on this system.

I know the clause CLANG_BUILT_STANDALONE would be made simpler if we could abandon testing in standalone build.

beanz edited edge metadata.May 31 2017, 11:15 AM

Is this really something we should be supporting? Building and testing clang with potentially out-of-sync lit or gtest seems undesirable to me.

It is worth noting that we do have mods to gtest, so supporting any standard distribution of it seems like a not great idea. The general approach in the past for standalone builds has been to disable testing unless an LLVM source tree is available, and I think that might be the right approach.

Also, this all kinda becomes moot if LLVM moves to a mono-repo (really not trying to troll here), because people actively developing LLVM projects will basically be forced to have LLVM source trees anyways.

Thoughts?

mgorny edited edge metadata.May 31 2017, 12:08 PM

This is going to break Gentoo. We're relying on the ability to specify LLVM_MAIN_SRC_DIR to provide unpacked LLVM sources with gtest. Without that, I don't see how we can use tests.

(note that I don't mind removing the llvm-config bit for it; but we need the cache variable to stay)

Is this really something we should be supporting? Building and testing clang with potentially out-of-sync lit or gtest seems undesirable to me.

This is actually what this patch is trying to avoid. For example prior to this patch, if you build and install llvm trunk to /usr/local, and then checkout an older stable branch in your llvm tree, when you try and build clang from trunk using the llvm install from /usr/local, it will pull lit and gtest from the LLVM source tree which is now much older than the checkout of clang you are using.

It is worth noting that we do have mods to gtest, so supporting any standard distribution of it seems like a not great idea. The general approach in the past for standalone builds has been to disable testing unless an LLVM source tree is available, and I think that might be the right approach.

Also, this all kinda becomes moot if LLVM moves to a mono-repo (really not trying to troll here), because people actively developing LLVM projects will basically be forced to have LLVM source trees anyways.

Thoughts?

beanz accepted this revision.May 31 2017, 3:25 PM

Ah. I see what you're saying. I was thinking of the mismatch in a different way, but your solution makes sense. LGTM.

This revision is now accepted and ready to land.May 31 2017, 3:25 PM

I don't think this would be ready to land.

mgorny requested changes to this revision.Nov 10 2018, 2:31 AM

Could you please rebase? I'm pretty sure this breaks our use but I can't test since it no longer applies cleanly.

This revision now requires changes to proceed.Nov 10 2018, 2:31 AM