Rebase, rename variables

I have done the deduping @phosek requested, and changed the variable names from CMAKE_* to LLVMPROJ_* which hopefully satisfies everyone's criteria. Happy with other non LLVM_ options too.

Dedup code, rename variables

This change introduces a lot of conditional code, that is not necessary. This change also uses CLANG_ outside clang/ which is messy. and confusing. Please clean up.

LGTM. I also can't see why it would act differently.

Thanks @MaskRay that's good to know.

If each project used a separate ${project_upper}_ENABLE_LTO I would be more comfortable with this.

Do we care about LLVM itself being built with LTO, or various runtime libs being built with LTO? LLVMConfig.cmake should *just* be about LLVM itself.

@ldionne Yeah that sort of thing is what I suspected. I am thinking maybe it isn't so bad that these projects can be built this way. IMO it should be permissible to combine any two CMake projects together if they are just to be built in parallel without any dependencies between them.

If we try to build docs with LLVM_ENABLE_RUNTIMES might it try to bootstrap them, wasting effort?

@tianshilei1992 that is a fair point. I would be open to calling them something else.

Rebase, fix some issues (by the looks of it)

Fix misspelled variable CLANG_CURRENT_SOURCE_DIR -> CLANG_SOURCE_DIR

Fix typo in compiler-rt

Rebase, avoid sed

I think I fixed the issue: I was confusing /lib stemming from lib subdirs in the source and /lib stemming from building things in a lib directory that will later be installed also to a lib directory. It is just the latter case that uses the suffix, and so just the latter case will be so seded.

Require LLVM_LIBDIR_SUFFIX in the sed

Rebase on top of D133828

OK. As long as we don't forget about it :).

In D132324 I also removed the hack in clang/lib/Driver/ToolChains/Linux.cpp, I think you want to do that too?

Might it be better to stort as a CMake list internally and then convert at only when used?

I need to review more but I am suspicious of this exact fix before we are looking up a LLVM-specific env inside what I think is a reusable project also useable by downstream projects.

Let's just revert this. I'll do it later today if no one beats me to it.

Whew, thanks!

https://lab.llvm.org/buildbot#builders/13/builds/24958 I am worried this failure is not spurious?

Fix bugs

Ah right, runtimes/ and llvm/runtimes are the two ways that remain per the plan.

Convert CMAKE_CFG_INTDIR as @sebastian-ne suggests, also .../bin

So this is in preparation for LLVM_DEFAULT_RUNTIMES in llvm/CMakeLists.txt doing a runtimes/ instead of llvm/runtimes/ build (among other changes)?

Code looks good.

Abandoning because the plan is to revert and because @ldionne is skeptical building libc++ without libc++abi ought to be supported anyways.

Fix more things for posterity

That sounds good to me too.

Redo sed mandating ending on word boundary

Thanks for that sleuthing, @kadircet.

https://reviews.llvm.org/D132411 should fix the issue @aaron.ballman mentioned.

https://reviews.llvm.org/rZORG3a209ca6c1b9 This is what I had started doing. but I am not sure it is a very good solution. I think I might write a discourse post with my thoughts.

I did a "soft revert" in rG952f90b72b3546d6b6b038d410f07ce520c59b48 which makes it a non-fatal error so everything keeps on working, but I can do a real revert too if that is preferred.

In 952f90b72b3546d6b6b038d410f07ce520c59b48 I relented and made it a non-fatal error until the remaining jobs are figured out.

Ah I see email about sphinx jobs defined out of tree :/ I will take a look at that, see if it is easy to fix.

The legacy build is no longer CI'd so the one failure here is no longer an issue.

Do the rename @phosek suggested

Use target_include_directories

Ah I would have to check both lists to support the legacy case. Ew.

OK Thanks @thakis --- I was confused why the last GN fixup added but didn't remove lines. That clears it up!