User Details
- User Since
- Mar 16 2018, 2:30 PM (261 w, 3 d)
Dec 9 2022
Nov 7 2022
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.
Nov 4 2022
Nov 2 2022
LGTM. I also can't see why it would act differently.
Oct 4 2022
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.
Sep 20 2022
If we try to build docs with LLVM_ENABLE_RUNTIMES might it try to bootstrap them, wasting effort?
Sep 14 2022
@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
Sep 13 2022
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 :).
Sep 11 2022
In D132324 I also removed the hack in clang/lib/Driver/ToolChains/Linux.cpp, I think you want to do that too?
Aug 30 2022
Might it be better to stort as a CMake list internally and then convert at only when used?
Aug 29 2022
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.
Aug 25 2022
Let's just revert this. I'll do it later today if no one beats me to it.
Aug 24 2022
Whew, thanks!
https://lab.llvm.org/buildbot#builders/13/builds/24958 I am worried this failure is not spurious?
Fix bugs
Aug 23 2022
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.
Aug 22 2022
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.
Aug 21 2022
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.
Aug 20 2022
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!