Arch Linux User Repository

When you have this package installed applications that are built against repo-llvm/clang WILL fail unless they are rebuild against this package.

This includes QTCreator, kdevelop , mesa, intel-compute-runtime, gnome-builder to name a few.

Archlinux currently has 3 llvm git implementations

1. This package

   • It aims to provide a full llvm/clang compiler environment for development purposes.
   • Supports cross-compiling , bindings for external stuff (python, ocaml etc) , and some things not in extra-llvm.
   • intended to be used with archlinux core,extra & community repos
   • CONFLICTS with extra llvm/clang packages
   • Currently there's no repo with binary versions

2. llvm-minimal-git

   • focuses on providing stuff needed for AUR mesa-git. Doesn't support cross-compiling or any bindings for external stuff like ocaml & python.
   • intended to be used with archlinux core,extra & community repos
   • compatible with extra llvm/clang packages
   • no repo with binary versions

3. packages created & maintained by Lordheavy, an arch developer

   • intended to be used with archlinux testing repos
   • sometimes has problems on systems where testing repos are disabled
   • uses same package structure as llvm/clang in official repos
   • source
   • binary versions in LordHeavys unoffical repo

I've looked good at clang-trunk , llvm-svn, repo llvm/clang packages and think this package is now on route to become a worthy successor to llvm-svn .

• llvm-libs-git holds the runtime libraries.

  It conflicts with the repo llvm-libs package. This is the only way to make sure the llvm linker from git is used, and that's needed for a full dev environment.

• llvm-git

  has llvm , clang, compiler-rt, ocaml & python bindings, polly , lld , lldb .

The Package now uses a new environment variable to make ninja behave, NINJAFLAGS. If you want to use it adjust the snippet below to your desired values and add it to makepkg.conf.

Incase you are satisfied with ninja defaults you don't need to do anything.

# Add to makepkg.conf
# limit ninja to 20 jobs
# requires special code in PKGBUILD
# see ninja --help for additonal options
NINJAFLAGS="-j20"

The check() function fails rather often, but I do suggest to build with them. If build fails due to test failure you can add --nocheck to skip the tests.

just a heads up, there appear to be 4 new python scrips in usr/libexec.

analyze-c++

analyze-cc

intercept-c++

intercept-cc

• shellcheck is not a suitable tool to check PKGBUILDs, https://bbs.archlinux.org/viewtopic.php?id=253125 is a discussion that shows several of the issues.

I could go into details but Aur comments are a bit to primitive. Maybe a thread on archlinux forum started by me ?

• openmp & libclc are indeed not included , but that's also true for flang, mlir and several others. If you (or other users) feel some component shoould be added, ask and rjahanbakhshi & I will look at it.

• makepkg has an option to skip check() function, the PKGBUILD doesn't need one

• Bindings / Documentation : this package aims to provide a full development environment for llvm trunk, uptodate documentation and bindings for external languages are not optional for that.

• archlinux has gcc as default compiler. Building with other compilers is done when software has a hard requirement on them or there are features that only work (well) with a specific compiler.

Also the repo llvm/clang pacakges is built against gcc, in my opinion llvm-git needs to do that also. Troubleshooting *-git packages used on multiple distros is hard enough as-is, allowing to choose a different compiler makes that much harder.

• I don't know russian (or any other cyrillic language), and translate functionality for technical stuff has a very long way to go.

• Performance isn't everything and I dislike llvm/clang license and feel their bug treatment process is is disorganised.

@Lone_Wolf sorry, first check your script with shellcheck. You are using bad and not safe shell sintax.

Your package not contain openmp and libclc, them use same packages https://github.com/h0tc0d3/arch-packages/issues/2.

I first maked package for llvm12 https://github.com/h0tc0d3/llvm-git and make fallback package it https://aur.archlinux.org/packages/llvm11-libs-bin/.

I prefer my llvm12-git version becuse it more stable than release. Your script can't skip test, can't skip OCaml and Go bindings(go can broke build), not have setting for build it with llvm, can't skip documentation. It's can speedup build and help for develop llvm. https://github.com/h0tc0d3/llvm-git

I wrote big arcicle about linux kernel and llvm 12 with LTO optimization. https://habr.com/ru/company/ruvds/blog/561286/

I ported more performance important packages to clang and speedup Arch Linux https://github.com/h0tc0d3/arch-packages

You are can test it. https://archlinux.club/

Maked kernel build script that can use llvm for build kernel https://github.com/h0tc0d3/kbuild

nullik , I became aware of the existence of your llvm12-git package yesterday.

Looked at it briefly and didn't see what purpose it had with llvm 12 in archlinux repos, so I created a deletion request.

I was surprised a TU did delete it without further discussion or wating for a response from you .

After seeing your comment and the deletion request you submitted for this package I decided to ignore the bad langauge and name calling and check llvm12-git thoroughly .

I cloned the llvm12-git aur repo, looked good at the pkgbuild. You do make different choices then the repo pacakge and try to facilitate building with non-gcc toolchain .

Unfortunately the latter is done by making the pkgbuild interactive, but that can be changed .

I do feel now I should have proposed changes instead of submitting a deletuion request.

You should reply on the aur-requests mailing list USING NORMAL LANGUAGE clarifying why llvm12-git is valuable and should be brought back.

A name change to something like llvm12-non-gcc-git would help to clarify the difference with repo llvm and other llvm packages .

P.S. I don't know what you mean by a curved buildscript or what problems you have with this package (apart from test fails that don't harm runtime performance and can be avoided by using --nocheck ).

I also don't see any aur comments or archlinux forum posts by you about problems with this package .

Thanks for the clarification Lone_Wolf. Since it's not been used in the official llvm PKGBUILD, I'm going to remove it here as well.

Technically the elements in PKGBUILD source array have a syntax of file::url .

url syntax is protocol://some-string-understood-by-the-protocol . Incase there's no protocol, makepkg currently expects the file to be present in the folder the PKGBUILD is in .

There are indeed package maintainers that use local://somefile to indicate users need to provide somefile themselves.

local:// is however an undocumented protocol which meaning can only be determined from makepkg / pacman sourcecode.

When to use it is a matter of style.

If I remember correctly I used it in this PKGBUILD to make sure users that downloaded just the PKGBUILD got a distinct error message when trying to build it.

(yes, such people DO exist).

rjahanbakhshi, it's your call if local:// stays in the PKGBUILD or not.

Yes, local://llvm-config.h is used but the file exists next to PKGBUILD so the user doesn't have to put it there.

But you're right. local:// is not necessary here. I'll update the PKGBUILD to simply use llvm-config.h instead of local://llvm-config.h

FWIW, using local:// scheme doesn't have any negative consequences, at least in the context of makepkg.

Based on https://wiki.archlinux.org/title/Nonfree_applications_package_guidelines

"In case you use the local:// scheme in a source array, makepkg behaves as though no scheme were specified, and the file must be manually placed in the same directory as the PKGBUILD."