PKGBUILD: add "clang" mode and rename _use_llvm_lto to _use_llvm#739
PKGBUILD: add "clang" mode and rename _use_llvm_lto to _use_llvm#739
Conversation
Add a new "clang" option to _use_llvm (formerly _use_llvm_lto) that uses Clang as the compiler with LTO disabled. This is useful for AutoFDO/Propeller profiling workflows and testing without the overhead of LTO linking. Signed-off-by: Peter Jung <admin@ptr1337.dev>
| return $? | ||
| } | ||
|
|
||
| _is_clang_build() { |
There was a problem hiding this comment.
Mainly added this for the QR Code check
There was a problem hiding this comment.
Pull request overview
This PR updates the linux-cachyos PKGBUILD to support building with Clang while keeping LTO disabled, by renaming the existing LLVM/LTO selector and expanding it with a new clang mode.
Changes:
- Rename
_use_llvm_ltoto_use_llvmand broaden its accepted values to includeclang. - Add
_is_clang_build()helper and update suffix/makedepends logic to treatclanglike other LLVM-based builds. - Update build/config/signing/header dependency logic to use the new
_use_llvmvariable and clang-build detection.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
1Naim
left a comment
1Naim
left a comment
There was a problem hiding this comment.
Some comments, I think we should keep _use_llvm_lto as a compat option for something like the kernel manager.
| [[ "$_use_llvm" = "thin" || "$_use_llvm" = "full" || "$_use_llvm" = "thin-dist" ]] | ||
| return $? | ||
| } | ||
|
|
||
| _is_clang_build() { | ||
| _is_lto_kernel || [[ "$_use_llvm" = "clang" ]] |
There was a problem hiding this comment.
| [[ "$_use_llvm" = "thin" || "$_use_llvm" = "full" || "$_use_llvm" = "thin-dist" ]] | |
| return $? | |
| } | |
| _is_clang_build() { | |
| _is_lto_kernel || [[ "$_use_llvm" = "clang" ]] | |
| _is_clang_build() { | |
| [[ "$_use_llvm" != "none" ]] | |
| } | |
| is_lto_kernel { | |
| is_clang_build && [[ "$_use_llvm" != "clang" ]] | |
| } |
Just a slight nitpick. Either works.
| # "thin": use Clang with ThinLTO - multiple threads, faster and uses less memory, may have a lower runtime performance than Full. | ||
| # "thin-dist": use Clang with distributed ThinLTO - https://discourse.llvm.org/t/rfc-distributed-thinlto-build-for-kernel/85934 | ||
| # "full": use Clang with Full LTO - 1 thread for Linking, slow and uses more memory, theoretically with the highest performance gains. | ||
| : "${_use_llvm:=thin}" |
There was a problem hiding this comment.
Would it make sense to replace "none" and "clang" to "no" and "yes" respectively to match the other config options?
There was a problem hiding this comment.
This would require then another variable for clang = no/yes and then which kind of lto mode?
There was a problem hiding this comment.
No just keep it all-in-one.
So instead of none, clang, thin, full, etc. There's no, yes, thin, full, etc.
Add a new "clang" option to _use_llvm (formerly _use_llvm_lto) that uses Clang as the compiler with LTO disabled. This is useful for AutoFDO/Propeller profiling workflows and testing without the overhead of LTO linking.
I will run some benchmarks to test the performance between ThinLTO + Propeller and Clang + Propeller. The main benefit we would have here, is that we can enable support for Rust and preparing for the future in case more and more drivers get depending on it.
The QR_CODE Bluescreen is pretty nice and we can also implement an own site for this.
Will enhance to other PKGBUILDs when reviewed